-
-
Notifications
You must be signed in to change notification settings - Fork 31.9k
Generalize reusable Windows CI jobs #121766
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
Conversation
Sometimes, GitHub Actions turn things into strings when passing the data around. So it's usually safer to turn them into proper booleans in expressions explicitly.
Previously, it didn't have a human-readable explanation which is a bad tone as it's less obvious how it's supposed to be used.
Previously, it was duplicated in each job which is not DRY.
d97631c
to
2a92204
Compare
Previously, the reusable windows workflow defined a number of per-arch jobs with a lot of copy-paste. Now, there is a single job and a matrix definition on the calling side.
Previously, these were defined through two separate matrices but there is no technical reason to keep them like that.
2a92204
to
21a36a2
Compare
Thanks for the PR. A quick note for myself, will come back to review properly later: So before, the Windows jobs showed up in the big misc box at the bottom (marked in yellow): ![]() https://github.com/python/cpython/actions/runs/9929374848 With this PR, they're in their own Windows box: ![]() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, the config feels a bit cleaner this way.
(cherry picked from commit 7982363) Co-authored-by: Sviatoslav Sydorenko (Святослав Сидоренко) <wk@sydorenko.org.ua>
Sorry, @webknjaz and @hugovk, I could not cleanly backport this to
|
GH-121775 is a backport of this pull request to the 3.13 branch. |
Extra note: one job name changed from |
GH-121776 is a backport of this pull request to the 3.12 branch. |
Manual backport: #121776 |
(cherry picked from commit 7982363)
FTR, this happens because of a weird corner case in GHA. Basically, it renders some of the job group representations differently depending on whether there's interpolation syntax in |
(cherry picked from commit 7982363)
@webknjaz This PR can't be merged: https://github.com/python/cpython/actions/runs/9950331379/job/27488343862?pr=121831
Do you know what is needed? |
Previously, those flags would sometimes end up having empty string values which tends to break evaluating them as JSON. This patch adds `false` fallbacks to all such outputs. This allows feeding them to `fromJSON()` without a fear of them causing surprising internal behaviors in the GitHub Actions CI/CD workflows platform itself [[1]]. The behavior observed was that some skipped jobs wouldn't show up in the workflow sidebar view at all, would display in the graph view as `Waiting for pending jobs` and in the `${{ needs }}` context, they would have a `result: failure` entry. This should help make PRs like python#121831 mergeable again. [1]: python#121766 (comment)
Previously, those flags would sometimes end up having empty string values which tends to break evaluating them as JSON. This patch adds `false` fallbacks to all such outputs. This allows feeding them to `fromJSON()` without a fear of them causing surprising internal behaviors in the GitHub Actions CI/CD workflows platform itself [[1]]. The behavior observed was that some skipped jobs wouldn't show up in the workflow sidebar view at all, would display in the graph view as `Waiting for pending jobs` and in the `${{ needs }}` context, they would have a `result: failure` entry [[2]]. This should help make PRs like python#121831 mergeable again. [1]: python#121766 (comment) [2]: https://github.com/python/cpython/actions/runs/9950331379/job/27501637459?pr=121831#step:2:244
Previously, those flags would sometimes end up having empty string values, which tends to break evaluating them as JSON. This patch adds `false` fallbacks to all such outputs. This allows feeding them to `fromJSON()` without a fear of them causing surprising internal behaviors in the GitHub Actions CI/CD workflows platform itself [[1]]. The behavior observed was that some skipped jobs wouldn't show up in the workflow sidebar view at all, would display in the graph view as `Waiting for pending jobs` and in the `${{ needs }}` context, they would have a `result: failure` entry [[2]]. This should help make PRs like python#121831 mergeable again. [1]: python#121766 (comment) [2]: https://github.com/python/cpython/actions/runs/9950331379/job/27501637459?pr=121831#step:2:244
Previously, those flags would sometimes end up having empty string values, which tends to break evaluating them as JSON. This patch adds `false` fallbacks to all such outputs. This allows feeding them to `fromJSON()` without a fear of them causing surprising internal behaviors in the GitHub Actions CI/CD workflows platform itself [[1]]. The behavior observed was that some skipped jobs wouldn't show up in the workflow sidebar view at all, would display in the graph view as `Waiting for pending jobs` and in the `${{ needs }}` context, they would have a `result: failure` entry [[2]]. This should help make PRs like python#121831 mergeable again. [1]: python#121766 (comment) [2]: https://github.com/python/cpython/actions/runs/9950331379/job/27501637459?pr=121831#step:2:244
Previously, those flags would sometimes end up having empty string values, which tends to break evaluating them as JSON. This patch adds `false` fallbacks to all such outputs. This allows feeding them to `fromJSON()` without a fear of them causing surprising internal behaviors in the GitHub Actions CI/CD workflows platform itself [[1]]. The behavior observed was that some skipped jobs wouldn't show up in the workflow sidebar view at all, would display in the graph view as `Waiting for pending jobs` and in the `${{ needs }}` context, they would have a `result: failure` entry [[2]]. This should help make PRs like python#121831 mergeable again. [1]: python#121766 (comment) [2]: https://github.com/python/cpython/actions/runs/9950331379/job/27501637459?pr=121831#step:2:244
Back-referencing the possible fix: #121848 |
(cherry picked from commit 7982363)
Previously, both the reusable and calling workflows had a lot of unnecessary duplication in the windows job definitions. This patch simplifies that into a single parametrized job that is included though a matrix in different modes.