Fix update-supported-enterprise-server-versions.yml workflow
#3284
Conversation
There was a problem hiding this comment.
Pull Request Overview
This PR fixes a failing workflow that updates supported GitHub Enterprise Server versions. The main fix adds the missing npm ci step before npm run build, while additional improvements include enabling workflow testing via pull requests, optimizing repository checkout with sparse-checkout, and refactoring the commit/PR creation logic into separate steps.
Key Changes
- Added
npm cibeforenpm run buildto ensure dependencies are installed - Split commit preparation and PR creation into separate steps with conditional logic to prevent PR creation during pull_request workflow runs
- Added pull_request trigger to enable testing workflow changes in PRs
| repository: github/enterprise-releases | ||
| token: ${{ secrets.ENTERPRISE_RELEASE_TOKEN }} | ||
| path: ${{ github.workspace }}/enterprise-releases/ | ||
| sparse-checkout: releases.json |
There was a problem hiding this comment.
The sparse-checkout parameter should be an array, not a string. According to the actions/checkout documentation, sparse-checkout expects a list of patterns, one per line.
Should be:
sparse-checkout: |
releases.json| sparse-checkout: releases.json | |
| sparse-checkout: | | |
| releases.json |
henrymercer
left a comment
There was a problem hiding this comment.
Nice, thanks! We should also look at reporting failures so we notice if a scheduled workflow starts failing in the future.
This has been failing for a while. The first commit should fix the issue that caused it to fail, while the others are slight improvements.
Risk assessment
For internal use only. Please select the risk level of this change:
Which use cases does this change impact?
CI only.
How did/will you validate this change?
CI.
If something goes wrong after this change is released, what are the mitigation and rollback strategies?
How will you know if something goes wrong after this change is released?
CI.
Merge / deployment checklist