Repository navigation
Consolidate CI hooks - #299
Conversation
|
This might be considered a matter of taste - but personally I like having all my CI jobs visible in a singular workflow in Actions. |
|
Ah, because of the way the job names are generated (pre-pending their caller and |
sea-bass
left a comment
There was a problem hiding this comment.
I like this as well, so we can merge the 2 PRs as one. I can go into the admin settings and change the required checks to pass after the fact.
Let me know when/if you want to consolidate these 2 PRs and we shall get it through.
|
Would it make sense to also move the current jobs that live at the top level of I could go either way personally, just thinking about how to prevent more faffing about with GitHub settings. |
|
That seems like a good idea for consistency! |
42a2879 to
40522fb
Compare
| @@ -1,4 +1,4 @@ | |||
| name: build_and_test | |||
| name: CI | |||
There was a problem hiding this comment.
Changed this name while we're gonna be messing with names anyway - since this workflow just orchestrates "CI" in general.
By invoking format and build_pypi_wheels from workflow_call, we ensure that our CI trigger and schedule strategy does not drift from job to job.
8ff35c2 to
8dc0f3a
Compare
|
we can do some more cosmetic tweaking to the workflow names and job names once we run and see how they look in practice. they might be a bit verbose right now |
| - name: Sanitize tag name | ||
| id: sanitize_tag | ||
| run: | | ||
| BRANCH="${{ github.head_ref || github.ref_name }}" | ||
| TAG="${BRANCH//\//-}" | ||
| echo "tag=$TAG" >> $GITHUB_OUTPUT |
There was a problem hiding this comment.
In a follow-up PR (since I don't want to risk functional changes in this PR that's mostly cosmetic), I think we should move this up to the root workflow and pass the tag name as an argument to the two jobs that use it.
Make the contents of the job clear in its name and remove inline YAML logic.
8dc0f3a to
897a7ce
Compare
EzraBrooks
left a comment
There was a problem hiding this comment.
Thoughts on these proposed names for the folderization of the workflow?
c180eb3 to
8ba816a
Compare
8ba816a to
1761eed
Compare
|
I got a bit lost in the sauce on changing the names of things but I think it looks really nice now. |
| assert "workflow_call:" in workflow | ||
| assert "pull_request:" not in workflow | ||
| assert "push:" not in workflow | ||
| assert "workflow_dispatch:" not in workflow |
There was a problem hiding this comment.
Removed, right? This test now fails for me locally,
> assert "workflow_dispatch:" not in workflow
E AssertionError: assert 'workflow_dispatch:' not in 'name: Build...und: error\n'
E
E 'workflow_dispatch:' is contained here:
E name: Build PyPI wheels
E
E on:
E workflow_dispatch:
E workflow_call: {}...
E
E ...Full output truncated (133 lines hidden), use '-vv' to show
That said does this get run by anything?
| assert "workflow_dispatch:" not in workflow |
There was a problem hiding this comment.
failing locally but not in CI? suspicious..
There was a problem hiding this comment.
It appears this test has never been invoked by CI. It seems like it's mostly just AI ramblings. Should I just delete it?
There was a problem hiding this comment.
A non-functional, non-executed test definitely doesn't add value... Seems like it was added in the initial wheels setup, #247.
So since we haven't been using it I would vote delete. But if someone who knows more about python packages (namely, everyone) than I do might see the value in actually wiring it to something...
There was a problem hiding this comment.
I actually have an incoming draft that unifies the wheel build into the new superbuild. Also, the CI job for building the wheels already sanity-checks them by importing them
sea-bass
left a comment
There was a problem hiding this comment.
Updated naming LGTM, gonna fiddle with the required checks now

By invoking format and build_pypi_wheels from workflow_call, we ensure that our CI trigger and schedule strategy does not drift from job to job.