Skip to content

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

Open
nelson-parente wants to merge 2 commits intomasterfrom
fix/create-release-trigger-build
Open

fix(ci): trigger CLI build after creating release tag#1626
nelson-parente wants to merge 2 commits intomasterfrom
fix/create-release-trigger-build

Conversation

@nelson-parente
Copy link
Copy Markdown
Contributor

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

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>
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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants