Skip to content

fix(ci): trigger CLI build after creating release tag#1626

Merged
cicoyle merged 4 commits into
masterfrom
fix/create-release-trigger-build
Apr 22, 2026
Merged

fix(ci): trigger CLI build after creating release tag#1626
cicoyle merged 4 commits into
masterfrom
fix/create-release-trigger-build

Conversation

@nelson-parente

@nelson-parente nelson-parente commented Apr 9, 2026

Copy link
Copy Markdown
Contributor

Summary

  • Adds a trigger job to create-release.yaml that explicitly calls gh workflow run dapr_cli.yaml after the tag is created
  • Same pattern already used in dapr/dapr (see trigger job)

Tags pushed by a workflow's token don't reliably trigger other
workflows (known GitHub Actions limitation). This meant dapr_cli.yaml
never fired after create-release.yaml pushed the tag, requiring
manual tag pushes to cut CLI releases.

Add a trigger job (same pattern as dapr/dapr) that explicitly calls
gh workflow run dapr_cli.yaml after the tag is created.

Signed-off-by: Nelson Parente <nelson_parente@live.com.pt>
@nelson-parente nelson-parente requested review from a team as code owners April 9, 2026 14:36
Without workflow_dispatch, the create-release trigger job cannot
invoke this workflow via gh workflow run. This is required for
the create-release automation to work.

Matches dapr/dapr's dapr.yml which already has workflow_dispatch.

Signed-off-by: Nelson Parente <nelson_parente@live.com.pt>
Comment thread .github/workflows/create-release.yaml Outdated
env:
GITHUB_TOKEN: ${{ secrets.DAPR_BOT_TOKEN }}
run: |
gh workflow run dapr_cli.yaml --repo dapr/cli --ref v$(echo '${{ inputs.rel_version }}' | sed -r 's/^[vV]?([0-9].+)$/\1/')

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it'd be better to use the workflow_call approach instead.
When using workflow_call in the target workflow, we can invoke it with uses: ./.github/workflows/dapr_cli.yml, and it runs the workflow as part of the current workflow, so if the dapr_cli workflow fails, the release workflow will also show red.

Maybe we prefer to keep it consistent with dapr/dapr, but I think the workflow_call approach is better in this case.

Switch from gh workflow run (workflow_dispatch) to workflow_call so the
CLI build runs as part of the release workflow. This makes build failures
visible directly in the release workflow status.

- Add workflow_call trigger with tag input to dapr_cli.yaml
- Override GITHUB_REF and checkout ref when called via workflow_call
- Update publish conditions to also check inputs.tag
- Remove redundant publish step condition (already guarded at job level)

Signed-off-by: Nelson Parente <nelson_parente@live.com.pt>
@cicoyle cicoyle merged commit 235f86a into master Apr 22, 2026
27 checks passed
@github-project-automation github-project-automation Bot moved this from Backlog to Done in v1.18 Release Tracking Board May 4, 2026
@nelson-parente nelson-parente added this to the v1.18 milestone May 4, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Status: Done

Development

Successfully merging this pull request may close these issues.

4 participants