ci: Remove check workflow and filter on branch name #253
Conversation
|
The behaviour that all pushes to a PR are picked up is demonstrated by me |
DiamondJoseph
changed the title
|
I'm pretty neutral on this one. What are we trying to achieve, just simpler CI or to encourage people to make PRs earlier in the development cycle? |
|
Simpler CI and make the
When there could be 5+ panes of workflows (see blueapi) it's just one more piece of visual noise. |
|
Yeah OK, I like this change. |
|
I'm afraid that I'm rather attached to CI running in branches. But maybe I need to change my workflow. Being forced to make a draft PR means that I'm less likely to forget I have made some changes in a branch and not yet PRed them. So maybe I'm convinced this is a good thing |
|
Ok, if you've convinced @gilesknap and I can't remember who wanted this in the first place then I'm happy to merge this if there are no other objections. I will assume that you have tried this out somewhere and it works as expected... |
|
This does represent a not immediately obvious change to workflow. Should we mention this in the docs? |
I've added an ADR with some rationale and the expected changes |
I've tried it out here with the additional commits to the branch, and in a personal project, where CI is run only when I expect it to. |
|
@AlexanderWells-diamond points out that this doesn't run on tags, but the CI does not appear to currently run on tags- they could be added simply enough. |
I usually make beta releases in branches. I understand that there is differing opinions on this. |
|
I'm happy that we can run CI on PR or tag. Approved again. |
|
Are we are squash merging this given the merge commit? |
If no-one has adopted this elsewhere then that seems reasonable |
Re-fixes the issue in #253 which made modifications to only one of the ci.yaml files and therefore only to this repository's workflows not the workflows of generated repos.
Removes the check workflow and using it to deduplicate PRs and pushes: CI should be run on all PRs and also on
mainbranch: pushes to PRs are already picked up by the pull_request filtering: "By default, a workflow only runs when a pull_request event's activity type is opened, synchronize, or reopened.", the definition ofsynchronizecan be found in the documentation: "A pull request's head branch was updated. For example, the head branch was updated from the base branch or new commits were pushed to the head branch."E: TC believes someone at some point wanted CI to run on branches that do not have open PRs, because when a PR is opened he gets notified whether it is draft or not. This does require that now a draft PR is opened for CI to run, but does anyone have a use case for running CI against a branch without even a draft PR?