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-ci directory-like component. By "directory-like component" I mean names like run-ci/foo, run-ci/foo/bar, foo/run-ci/bar, foo/bar/run-ci/baz, but not run-ci or foo/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, because foo and foo/run-ci cannot 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-branches branch 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.)
As discussed in https://github.com/Byron/gitoxide/pull/1499#issuecomment-2278901849 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.)