16

Is there any way we can run multiple jobs in a single runner or share the Github actions workspace between jobs?

In my organization, development teams use multiple reusable workflows created and managed by multiple teams. Team build creates and manages build.yaml that builds applications. My team creates and manages analysis.yaml that does data analysis on application builds and archives the built artifacts.

Developments teams are planning to use both of our workflows in their application workflow. For my team's workflow to work, my workflow needs to access the built code (target directory for maven builds, build directory for gradle builds and node_modules for npm builds).

  • Is there a way to run my reusable workflow on the runner where the code is built?
  • Is there a way I can get access to the workspace where the code is built (I searched other answers and learnt that I can use the upload action and cache action). Are there other ways I can accomplish this and run my reusable workflow on the build runner itself?
  • Will I accomplish this better with a composite action rather than using a reusable workflow?

I have the following example.

build.yaml

on:
  workflow_call
  inputs:
    build:
      description: Build type
      required: true

jobs:
  Build:
    runs-on: self-hosted
    steps:
      - name: Building apps
      - if: ${{inputs.build=='gradle'}}
        run: |
          gradle build

analysis.yaml

on:
  workflow_call
  inputs:
    analysis:
      description: Build type
      required: true
      type: boolean

jobs:
  Build:
    runs-on: self-hosted
    steps:
      - name: Building apps
      - if: ${{inputs.analysis}}
        run: |
          #Run ML build analysis
          #Archive the build artifacts

workflow.yaml

on:
  push:
    branches: [main]

jobs:
  Build:
    uses: buildteam/.github/workflows/build.yaml@main
    with:
      build: gradle

  Analysis:
    uses: analysis/.github/workflows/analysis.yaml@main
    with:
      analysis: true

Haunted
  • 345
  • 1
  • 2
  • 11
  • I believe jobs are isolated on purpose. If you still need the two to communicate, the easiest would probably be uploading and downloading artifacts using: https://github.com/actions/upload-artifact – rethab Mar 23 '22 at 08:17
  • Does this answer your question? [In a github actions workflow, is there a way to have multiple jobs reuse the same setup?](https://stackoverflow.com/questions/65242830/in-a-github-actions-workflow-is-there-a-way-to-have-multiple-jobs-reuse-the-sam) – gcode Apr 08 '23 at 20:18

2 Answers2

4

No, as far as I know it is not possible to share workspace between jobs, at least for now.

  • Is there a way to run my reusable workflow on the runner where the code is built?

  • Is there a way I can get access to the workspace where the code is built (I searched other answers and learnt that I can use the upload action and cache action). Are there other ways I can accomplish this and run my reusable workflow on the build runner itself?

You could force that by using unique runner labels. By defining unique label on a runner you can then reference that runner in both jobs with runs-on

  • Will I accomplish this better with a composite action rather than using a reusable workflow?

This is more of opinion based question, but I'll answer it anyway. Yes, I definitely think composite action would be a better solution in this case, especially because both build and analysis workflows seem simple and don't use secrets. But you should check the docs for differences between these two, there are some limitations.

frennky
  • 12,581
  • 10
  • 47
  • 63
2

You can get the runner of the first job and pass it as output to the following jobs.

name: main
on: 
  push: { branches: [main] }

jobs:
  get-runner:
    name get a runner to use for this workflow
    if: ${{ always() }}
    runs-on: custom-runner
    outputs:
     RUNNER: ${{ runner.name }}
    steps:
      - run: echo "selected runner = ${{ runner.name }}"

 other-job:
    name: another job
    needs: get-runner
    runs-on: ${{needs.get-runner.outputs.RUNNER}}
    steps:
      ...

This approach only works with custom runners.