joshjohanning / container-job-test

2 stars 1 forks source link

Workflows #1

Open mheras opened 1 year ago

mheras commented 1 year ago

Hi Josh,

I really like the idea of building the docker image that is used for running the jobs, but how do you force the image creation workflow to run BEFORE the job workflow?

Let's say you commit changes in both the image Dockerfile and the source code of one of your apps at the same time... Both workflows will start running at the same time, and nothing prevents the jobs to grab an older version of the docker image from the registry...

Thank you!

joshjohanning commented 1 year ago

@mheras

Hmm, nothing really comes to mind for making sure the ordering is correct 100% of the time if they are both triggered from a push event, and you want to use the latest-built image.

If you wanted the docker build job to always trigger the other job, you could use the workflow_dispatch trigger in the subsequent job, and something like this in the docker build job to fire off the job:

- name: Trigger Workflow
  uses: actions/github-script@v6
  with:
    script: |
      github.rest.actions.createWorkflowDispatch({
        owner: context.repo.owner,
        repo: context.repo.repo,
        workflow_id: 'new-workflow.yml',
        ref: '${{ github.head_ref }}',
        inputs: {
          "workflow-input-1": "value-1",
          "workflow-input-2": "value-2",
        }
      })

I talk about this a little more in this post on how this can work. https://josh-ops.com/posts/using-github-checks-api/#implementation

A change in September allows us to use this with the ${{ github.TOKEN }}, as we previously would have had to use a PAT or something.

This wouldn't account for scenarios where the docker build job doesn't change / doesn't need to be ran and you want to only run your build job.


A crazy out-of-the-box alternative would be to:

  1. In the build job, have a pre / setup job
  2. sleep for ~5s to wait for all the the docker build to be queued, if necessary
  3. Have the workflow ID for the docker build job, can retreive via gh workflow list -R your-org/your-repo or gh api /repos/$org/$repo/actions/workflows
  4. see if any jobs are queued; can do this via gh workflow view $workflow_id -R your-org/your-repo or gh api --method GET /repos/$org/$repo/actions/workflows/$workflow_id/runs -F per_page=$WORKFLOW_RUNS_TO_CHECK
  5. If job is queued or running, wait for x seconds
  6. Check again, repeat if necessary
  7. Then, your actual build job would be a separate job that is dependent on this setup job. it would then run and use the latest docker tag.
mheras commented 1 year ago

@joshjohanning Thank you very much for your quick and detailed response!