Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Better handling for required workflows #2356

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 4 commits into from
Jul 1, 2024

Conversation

marcogario
Copy link
Contributor

Return the workflow path from the run rather than trying to fetch the workflow information when the workflow information is missing or refers to a required workflow.

This fixes the error:

Error: As of January 2024, this feature is fully deprecated and creating required workflows is only available with repository rulesets. All existing workflows have been automatically migrated to rulesets. Learn more about rulesets: https://github.blog/2023-10-11-enforcing-code-reliability-by-requiring-workflows-with-github-repository-rules/

I've tested this by setting up a required workflow using the action version from this version and confirmed it works.

Note: We are reporting the path as if it exists in the current repo, but that is not the case. Logic that relies on making a distinction here might be affected.

Merge / deployment checklist

  • Confirm this change is backwards compatible with existing workflows.
  • Confirm the readme has been updated if necessary.
  • Confirm the changelog has been updated if necessary.

Return the workflow path from the run rather than trying to fetch the workflow
information when the workflow information is missing or refers to a required workflow.
@marcogario marcogario requested a review from a team as a code owner June 27, 2024 16:40
// For required workflows, the workflowUrl is invalid so we cannot fetch more informations
// about the workflow.
// However, the path is available in the original response.
return runsResponse.data.path as string;
Copy link
Contributor

Choose a reason for hiding this comment

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

runsResponse.data.path Why isn't this value always correct? Is it because there are edge cases in normal workflow runs where the workflow may have been moved?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I don't know. I think it should be correct, but I can try to dig into the server-side logic to try to be sure. Right now this was meant to be backwards compatible.

Co-authored-by: Andrew Eisenberg <[email protected]>
@marcogario marcogario added the Rebuild Re-transpile JS & re-generate workflows label Jul 1, 2024
@github-actions github-actions bot removed the Rebuild Re-transpile JS & re-generate workflows label Jul 1, 2024
henrymercer
henrymercer previously approved these changes Jul 1, 2024
Copy link
Contributor

@henrymercer henrymercer left a comment

Choose a reason for hiding this comment

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

LGTM, this is clearly correct. As Andrew mentions, it would be nice to see if we can use runsResponse.data.path directly, but we should test this thoroughly to avoid stale tips.

@henrymercer
Copy link
Contributor

@marcogario Unfortunately the rebuild workflow doesn't know how to fix linter errors — would you mind addressing these manually?

@marcogario marcogario merged commit ee4ad8b into main Jul 1, 2024
310 checks passed
@marcogario marcogario deleted the marcogario/require_workflows_path branch July 1, 2024 12:58
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.

3 participants