Generalize reusable Windows CI jobs - #121766
Conversation
Sorry, something went wrong.
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.
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.
|
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: 
|
Sorry, something went wrong.
hugovk
left a comment
There was a problem hiding this comment.
Thanks, the config feels a bit cleaner this way.
Sorry, something went wrong.
(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 3.12 due to a conflict. cherry_picker 7982363b479e22fffc72481e54c9f40ace8a0021 3.12 |
Sorry, something went wrong.
|
GH-121775 is a backport of this pull request to the 3.13 branch. |
Sorry, something went wrong.
|
Extra note: one job name changed from x86 to Win32 in the UI. I forgot to mention this but I think, this is more consistent even. |
Sorry, something went wrong.
|
GH-121776 is a backport of this pull request to the 3.12 branch. |
Sorry, something went wrong.
Manual backport: #121776 |
Sorry, something went wrong.
(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 name:. And it's especially odd if you want to have a static group name. For this, I invented a hack of adding ${{ '' }} to the end of the value just to trigger the better grouping behavior in the UI. |
Sorry, something went wrong.
(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? |
Sorry, something went wrong.
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 |
Sorry, something went wrong.
(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.