Dispatch release workflow from CI

[weppos]

Remove the use of wait-on-check-action, which forced both workflow to run. Instead, use the workflow_run to run the Release from the CI workflow.

See:

• dnsimple-java/.github/workflows/release.yml

  Lines 13 to 20 in 9e709d6

  	- name: Wait for tests to succeed
  	uses: lewagon/wait-on-check-action@v1.4.0
  	with:
  	ref: 'refs/heads/main'
  	running-workflow-name: 'Publish Client'
  	repo-token: ${{ secrets.GITHUB_TOKEN }}
  	wait-interval: 10
  	allowed-conclusions: success

• https://github.com/dnsimple/erldnsimple/blob/309f3bede42e73ae5b06b3e1252d6139d593c9a6/.github/workflows/release.yml#L3-L14

[lokst]

I believe that adding workflow_run like in https://github.com/dnsimple/erldnsimple/blob/309f3bede42e73ae5b06b3e1252d6139d593c9a6/.github/workflows/release.yml#L3-L14 would make the Release workflow run whenever the CI workflow completes for a push to the main branch, which is probably not what we want, since we sometimes want to combine many main branch commits into a release. (Plus, the tag information would be missing)

Also, upon checking, I believe that the current configuration doesn't force both workflows to run unnecessarily.

Our current release procedure is to wait for CI to complete after pushing to main before pushing the tag:

1. Commit and push the changes

    ```shell
    git commit -a -m "Release $VERSION"
    git push origin main
    ```

1. Wait for CI to complete.
1. Create a signed tag.

    ```shell
    git tag -a v$VERSION -s -m "Release $VERSION"
    git push origin --tags
    ```

And I see that the CI workflow only runs once for the same commit SHA; it doesn't get triggered again when the tag is pushed. For example, we can look at the recent workflow runs for the 3.0.2 release: https://github.com/dnsimple/dnsimple-java/actions/runs/16926245928 and https://github.com/dnsimple/dnsimple-java/actions/runs/16926268312

Looking at the timestamps for the CI workflow, we can see that the CI workflow was triggered earlier (by the push to main) and completed before the Release workflow started.

Looking at the Release workflow, we can see that it started after the CI workflow had ended, and the wait-on-check-action was able to use the results of the earlier completed CI workflow to proceed on to the next step without delay. (If the push to main and the tag push had happened in quick succession, we should see the wait-on-check-action waiting for the CI workflow to complete, which would also be what we want)

@weppos In light of these findings, do you think we can leave the current configuration as-is and close the issue?

[weppos]

I feel uncomfortable to rely on a third party action wait-on-check-action unless strictly necessary.

Wouldn't a combination of workflow_run + if check achieve the same result?

---
name: CI

on:
  push:
    branches:
      - main
  pull_request:
  workflow_dispatch:

---
name: Release

on:
  workflow_run:
    workflows:
      - "CI"
    types:
      - completed
    branches:
      - main

jobs:
  release:
    runs-on: ubuntu-latest
    if: ${{ github.event.workflow_run.conclusion == 'success' && github.ref_type == 'tag' }}

[weppos]

FWIW we have a number of different "solutions" we adopted across all the repos, and I'm actually looking forward to consolidating in a single, effective, recipe.

In https://github.com/dnsimple/dns_erlang/blob/main/.github/workflows/release.yml, for instance, we don't dispatch the workflow from the CI. We actually run it directly when there is a push for tags.

Pros:

• We validate the format of the tag matches v*.*.* so we don't run it on ANY tags

Cons:

• We ignore the result of the CI
• We ignore whether the CI run or not

This is another workflow that would be good to update to match the same process we have here.

I realized, while reviewing this workflow, that the solution I mentioned in the comment above may not:

• Run CI on tag push, therefore Release may never run
• Do not validate the tag format (hence it will run on ANY tag, even bla-bla-bla)

It should be trivial to implement both. I believe there is value in always running CI before any release, even if we push a tag, as we may incorrectly tag a wrong commit.

[lokst]

Thanks @weppos for the suggestions!

Regarding the workflow in https://github.com/dnsimple/dns_erlang/blob/main/.github/workflows/release.yml , I believe it is very similar to the workflow in this repository, (i.e. both are run directly when there is a push for tags) except that for this repository, the result of the CI workflow is checked via the third-party wait-on-check-action action whereas in dns_erlang, the result of the CI workflow is not checked.

I tested out the solution mentioned in #201 (comment), in a private repository, with some additional configuration to run the CI workflow on tag push and also validate the tag format:

---
name: CI

on:
  push:
    branches:
      - main
    tags:
      - v*.*.*
  pull_request:
  workflow_dispatch:

concurrency:
  group: ${{ github.workflow }}-${{ github.ref }}
  cancel-in-progress: true

jobs:
  test:
    name: Test
    runs-on: ubuntu-latest
    steps:
      - name: Checkout Code
        uses: actions/checkout@v5

---
name: Release

on:
  workflow_run:
    workflows:
      - "CI"
    types:
      - completed
    branches:
      - main

jobs:
  publish:
    name: Publish Client
    runs-on: ubuntu-latest
    if: ${{ github.event.workflow_run.conclusion == 'success' && github.ref_type == 'tag' }}
    steps:
      - name: Validate tag
        run: |
          TAG_NAME=${{ github.ref_name }}
          if [[ $TAG_NAME =~ ^v[0-9]+\.[0-9]+\.[0-9]+$ ]]; then
            echo "Tag $TAG_NAME is valid"
          else
            echo "Tag $TAG_NAME is invalid"
            exit 1
          fi
      - name: Checkout Code
        uses: actions/checkout@v5

However, based on these test results, I found that the Release workflow only got evaluated whenever the CI workflow was triggered by a branch push; the Release workflow would not be evaluated after a CI workflow that is triggered by a tag push.

I suspect that it is because workflow_run only supports workflows triggered by branch pushes. I also tried adding a tags under workflow_run but it seems that it is invalid syntax.

I think another alternative we could consider for removing the usage of the wait-on-check-action action is to try to emulate what it is doing, which I believe is calling the GitHub Checks API on the commit SHA.

[weppos]

However, based on these test results, I found that the Release workflow only got evaluated whenever the CI workflow was triggered by a branch push; the Release workflow would not be evaluated after a CI workflow that is triggered by a tag push.

Have you tried removing the "branches" section from the Release workflow? It's optional and likely limiting the run to the branch main. If we check for the tags refs below, it's plausible we don't need it.
https://docs.github.com/en/actions/reference/workflows-and-actions/events-that-trigger-workflows#limiting-your-workflow-to-run-based-on-branches

[lokst]

@weppos After some more experimenting, I would like to propose another alternative, which is to have the CI workflow create a workflow dispatch event to trigger the Release workflow whenever it is triggered by a tag push, for example by adding a step like below to ci.yml:

      - name: Trigger Release workflow
        if: ${{ github.ref_type == 'tag' }}
        uses: actions/github-script@v7
        with:
          github-token: ${{ secrets.GITHUB_TOKEN }}
          script: |
            const tag = process.env.GITHUB_REF.replace('refs/tags/','');
            await github.rest.actions.createWorkflowDispatch({
              owner: context.repo.owner,
              repo: context.repo.repo,
              workflow_id: 'release.yml',  // file name of the Release workflow
              ref: 'main',                  // run Release from default branch
              inputs: { tag }
            });

Then the Release workflow can be modified to only run on a workflow_dispatch event instead. It can validate the tag name from the input parameter.

on:
  workflow_dispatch:
    inputs:
      tag:
        description: 'Release tag'
        required: true

I did a quick test from a private repository and verified the flow:

Have you tried removing the "branches" section from the Release workflow? It's optional and likely limiting the run to the branch main. If we check for the tags refs below, it's plausible we don't need it.
https://docs.github.com/en/actions/reference/workflows-and-actions/events-that-trigger-workflows#limiting-your-workflow-to-run-based-on-branches

@weppos I will try this as well

[lokst]

@weppos I verified that removing the "branches" section from the Release workflow allows it to be evaluated when the CI workflow is triggered by a tag push 👍 I have implemented the changes to the workflow here: #218

[weppos]

@weppos I verified that removing the "branches" section from the Release workflow allows it to be evaluated when the CI workflow is triggered by a tag push 👍 I have implemented the changes to the workflow here: #218

Awesome! Do you feel confident with the solution? Can we document it as the "recommended tag-based" setup, and apply to all other similar repo?

[lokst]

@weppos Yes, though I think it'd be good to observe it working for this repository first. I'll document this setup and make a ticket for applying it to other similar repositories after the PR is merged and verified 🙂