Conversation
|
We usually just disable actions fully on our own fork. The check for the repo would work as well, but means we need to do it for all repo's one by one. I might prefer to do it in the github-actions instead then (check for The main repo means it won't work for release branches (which for |
|
@SerhatG I don't think doing this for all repo's one by one (especially library-ish repos like this one) is the wrong thing to do here tbh. Especially for stuff that publishes to some external thing, we should design what/when/where things are executed, instead of lean implicitly on whether a fork's gh action checkbox is turned on or off FWIW the repo/branch guard is standard in the guideline: |
|
On a more general note I don't think everything that happens in a github action needs to be flexibly provided by the top layer github actions wrapper either; there is room for custom considerations, such as whether the action is executed on this or that branch or remote or whatever |
The code-push workflow deploys a -SNAPSHOT to the internal Nexus, which needs the NEXUS_* secrets. Forks do not have those, so any fork push that matches the branch filter fails on the deploy step. Guard the job on the repository so it only runs on aerius/tools.
07db003 to
d33e74a
Compare
JornC
changed the title
The tag, pull_request and create-release workflows can run in a fork too. Same rule in every file, so it is not something to reason about per event.
JornC
changed the title
2 participants
This is part of a round of mass gha workflow refinements, where up to 2 rules are applied:
*_fixesbranchesFor this repo:
Rule 1 is applied to
on-code-push.yml(already in this PR),create-release.yml,on-new-tag.ymlandon-pull_request-opened-synchronize-reopened.ymlRule 2 has already been applied
LLM-generated technical summary
A job-level
if: github.repository == 'aerius/tools'stops the job in any fork while leaving behavior in the canonical repo unchanged. It is deliberately at job level rather than inside the shared composite actions inaerius/github-actions: a composite action has noon:block and can only gate individual steps, so a central version would still spin up the runner and run a full build before declining to publish.On a
pull_requesteventgithub.repositoryis the base repository, so the guard is false only when the PR's base is itself a fork. A PR from a fork into the canonical repo is unaffected.Note for anyone rehearsing a release in their own fork: a guarded job skips silently rather than failing, so the
if:line has to come out locally first.