Run CI on moderately more events #1507
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
When a branch is named with a non-trailing (i.e. directory-like) `run-ci` component, such as `run-ci/foo` or `bar/run-ci/baz`, pushing to the branch will run the CI test workflow under the same conditions that a push to `main` would run it. This is primarily to allow CI to work in forks even when there is no pull request, while still avoiding running it when it is not wanted. Note that forks still need to enable GitHub Actions workflows for this, or any workflows, to run in them.
- Trigger `msrv.yml` on the push event, for the same branches for which `ci.yml` is triggered on it. That is, make the corresponding change to the MSRV workflow that was made to the test workflow. - Remove outdated comments on `msrv.yml`. These comments already disagreed with the code, since they named `master` when the branch was `main`, and suggested that all pull requests would trigger the workflow when really was (and continues to be) also limited by branch. - Add `workflow_dispatch` to the `ci.yml` and `msrv.tml` workflows, so they can be manually run even for branches that are not named, and in the case of `ci.yml`, so it can be manually run even when changes are not made to any of the paths that are also needed to trigger it on the push or pull_request events. - Put `workflow_dispatch` last in the `release.yml` workflow that already had it. Currently it is a secondary way to trigger all workflows that include it. It was in practice the primary way to trigger `release.yml` when the push trigger was broken, but that is no longer the case since 286e388 (GitoxideLabs#1475). Even in testing, it is now most often run by pushing a tag. This brings its style in line with the style in `cron.yml`, where `workflow_dispatch` was already a secondary way to trigger the workflow and listed second.
This adds workflow_dispatch as an event trigger for `cifuzz.yml`. Since that should be sufficient to cover the rare case where one wishes to run it outside of a pull request against the `main` branch, this narrows the existing pull_request trigger to occur only on `main`, as is already the case in the other workflows that are intended to run more often than this one.
Byron
approved these changes
Aug 11, 2024
EliahKagan
added a commit
to EliahKagan/cargo-smart-release
that referenced
this pull request
Apr 13, 2025
This adds patterns besides the literal name `main` so CI runs on `push` to any branch that has `run-ci` as a non-trailing component. It also adds a `workflow_dispatch` trigger so the workflow can be run (on any branch) manually from the Actions tab. These are to make the workflow easier to run in forks, roughly analogous to GitoxideLabs/gitoxide#1507.
EliahKagan
added a commit
to EliahKagan/cargo-smart-release
that referenced
this pull request
Apr 13, 2025
This adds patterns besides the literal name `main` so CI runs on `push` to any branch that has `run-ci` as a non-trailing component. It also adds a `workflow_dispatch` trigger so the workflow can be run (on any branch) manually from the Actions tab. These are to make the workflow easier to run in forks, roughly analogous to GitoxideLabs/gitoxide#1507.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
As discussed in #1499 (comment) and below, it is useful to be able to run CI checks in forks even when not (or not yet) having opened a pull request. That is already feasible in two ways, but neither is ideal:
Commit and push directly to
mainin one's fork.Make another branch on which the workflows are modified.
Those approaches will still work. But with the changes in this PR, there are further options, which are usually better :
Name the feature branch with a
run-cidirectory-like component. By "directory-like component" I mean names likerun-ci/foo,run-ci/foo/bar,foo/run-ci/bar,foo/bar/run-ci/baz, but notrun-ciorfoo/run-ci. Of the three approaches facilitated here, this is probably the best one, when one knows one wants CI checks to run even outside of a pull request.The reasons for not treating it specially when it is the last or only component is that it is more likely to be meant (or be misinterpreted) as a description of a change to be made in that position. In the case of
foo/run-ci, that would be a mistake a significant fraction of the time, becausefooandfoo/run-cicannot exist in the same repository.Name the feature branch anything and, when one wishes for CI to run, make and push another temporary branch from it that matches the above naming convention. This is still simpler and much less confusing than creating a branch that has different contents, as was previously required.
Name the feature branch anything and, when one wishes for CI to run, trigger in manually for that branch through the workflow_dispatch event, available in the Actions tab.
I did not make the CI Fuzz workflow run on the push trigger, since it takes a while and is not even run on the push trigger on the main branch.
A small amount of additional, less important information is available in the commit messages.
The effect of this change, regarding naming branches for CI to run on push, can be observed in the
run-ci/ci-branchesbranch in my fork, which is the branch for this PR. CI ran in all three commits there. (I won't keep that branch forever, but the tip of it can be viewed by hash if anyone is ever interested later.)