Conversation
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
| f"rust-v{version}", | ||
| "--json", | ||
| "workflowName,url,headSha", | ||
| # Empirically, we have seen both "rust-release" and | ||
| # ".github/workflows/rust-release.yml" as the workflowName, so we | ||
| # check for both here. The docs are not clear on which is expected: | ||
| # https://cli.github.com/manual/gh_run_list | ||
| "--workflow", | ||
| ".github/workflows/rust-release.yml", |
There was a problem hiding this comment.
Account for workflowName path variant in alpha builds
The new --workflow .github/workflows/rust-release.yml logic tolerates the gh run list behavior change when resolving release workflows, but the alpha path still depends on fetch_workflow_url_for_version returning a run whose workflowName equals "rust-release". When the CLI returns .github/workflows/rust-release.yml (the scenario this patch targets), alpha staging still raises "Unable to locate workflow for version …" even though the run exists. Consider applying the same filtering (or checking both names) in fetch_workflow_url_for_version so both release and alpha flows succeed.
Useful? React with 👍 / 👎.
I am not sure what is going on, as #3660 introduced this new logic and I swear that CI was green before I merged that PR, but I am seeing failures in this CI job this morning. This feels like a non-backwards-compatible change in
gh, but that feels unlikely...Nevertheless, this is what I currently see on my laptop:
Looking at sample output from an old GitHub issue (cli/cli#6678), it appears that, at least at one point in time, the
workflowNamewas not the path to the workflow.