-
-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
Allow manually running GitHub Actions workflows and use consistent file extension #2215
Conversation
I'll give other people some time to review to see if they want to. |
I don't like this branch restriction, because I prefer to check the CI passes for my own fork's feature branch first, before creating a PR. That way I can iterate and only create the PR when it's ready, and don't need to create more noise in the main repo. With a restriction, the options are:
I think the double build thing isn't such a big problem for open source: normally the push build is done on the contributor's fork's CI, and the PR build is done on the upstream CI, so we won't be tying up the project's CI. And for this repo, the CI is very quick: 1m19s + 30s. If it really is a problem, a compromise is to allow something like |
@hugovk good one! If I need something similar, I would just open an intermediate PR in my own fork to Later, you can close your own PR and re-create it from your What do you think? 🙂 |
Yes, that is a fourth option, but I'm less inclined to do that as then I'll end up opening and closing hundreds of PRs. I'll likely do option 2 (work in Generally speaking, I think contributors should be encouraged to easily test in their forks before creating PRs. Very often contributor guides recommend running tests locally, which is good, but can involve installing a lot of stuff. Sometimes they have tox, making it easy, but I might not have all Python version installed, and it can be slow. But CIs are extremely useful and powerful, and often test on a much bigger matrix than I have access to: multiple operating systems, architectures, extra combinations. They're faster than my laptop. If a passing CI is considered a merge requirement, let us fail fast and find problems earlier in the contribution loop. On the other hand, if the contributor isn't even interested in the CI, chances are they've not enabled it, and we're not even saving anything. How much of a problem really is it to run the CI twice? Once in the contributor's fork and one in the upstream, separate accounts with separate limits/queues. |
This is only a problem if:
For example, it is important for CPython: https://github.com/python/cpython/blob/45d44b950f1dab0ef90d0a8f4fa75ffaae71500b/.github/workflows/build.yml#L10 But, I now think that this is not the case for |
Let's consider the main Cpython repo:
Check.
Looks like this is not the case. I see only three feature branches by two core developers: A quick check of the first page of PRs: 6 PRs by 3 core developers, all from their own forks: Even the miss-islington bot uses, erm, her/their/its(?) own fork for branches.
I believe it's not and is an impediment to contribution: I often temporarily disable that restriction before creating PRs. But I'm not going to take up this case now :)
Agreed on both bullet points. |
@hugovk 👍 I've removed branch name restriction, but added |
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.
Looks good, workflow_dispatch
can be useful!
https://github.blog/changelog/2020-07-06-github-actions-manual-triggers-with-workflow_dispatch/
@sobolevn if adding I've never known what the preferred extension is for YAML (this site says A |
Looking at the contents of the 4,764 sdists I've managed to download from the top 5,000 on PyPI:
And:
|
The statistician in me wants to ask about measurement error bias arising from sdists -- how many include the full repo vs just source, tests, docs etc. But for a pretty inconsequential thing I probably shouldn't 😁 A |
FWIW, while I do find workflows running on my forks to be annoying, GH Actions can always be disabled with a couple clicks under your fork's repo settings, which is how I handle it and for contributors that use it on their forks (I personally run the pre-commit checks and both build systems locally myself), better than the workarounds. Typically, we (Spyder projects and other things I maintain) limit it to only pushes and pull requests against designated branches, to avoid duplication, and at least for the Spyder project and others I work on, submitting a draft PR early to run the CIs isn't really seen as too noisy, at least more than duplicate check runs. We typically use: on:
push:
branches:
- master
- main
- '*.x'
- 'staging*'
pull_request:
branches:
- master
- main
- '*.x'
- 'staging*' This runs against our main branch, release branches, and any special "staging" branches, which can be pushed to in order to test changes before merging to a production branch (which can be used by contributors on their own repos here).
FYI, that site is the official YAML spec, which as you mention authoritatively states that the extension should be |
To add a vote in favour of the PR as it currently stands -- I'm with Hugo and find CI on my fork really useful. RE special branch names -- perhaps a reasonable solution when CI takes ages or a lot of resource, but it is (IMO) not an amazing precendent, as projects will inevitably use different magic phrases, leading to frustration. The key point here for PEPs is that CI is really quick, and hopefully at some point soon will be even quicker as there'll only be one build job, not two. RE suffixes -- I don't mind! A |
@sobolevn please could you resolve the merge conflicts? |
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.
While the preferred extension per the official spec is .yaml
, not .yml
, its more important that they be consistent one way or the other and its not worth bikeshedding over. As for the trigger config, makes sense to me for this repo 👍
Looks like the merge conflicts are fixed and we all approve, so going ahead with this. Thanks @sobolevn ! |
I would like to repeat that «consistency» for its own sake, and especially about such a tiny thing as a file extension, is not a sufficient reason to do changes in Python projects (CPython for sure, for related projects it depends). Increasing consistency (often meaning uniformity or alignment of details) is not a goal in itself; it should be: fixing an inconsistency that does trip up people, or that makes development tools harder to use (if they have glob patterns for example), or that creates another kind of trouble or impediment for people reading, using or changing code or other files. There is much more value in spending time to fixi reported issues than observing inconsequential misalignment of details and «fixing» them. (I am not saying that attention to details is bad, or that new code/docs should not strive to be generally consistent internally and with existing conventions, or that there doesn‘t exist sloppiness that does cause issues down the road. It’s about balance in judgment and knowing where to invest time. And thank you for all your efforts and time spent on the project!) |
Several changes:
yaml
->yml
, which is the prefered extension