You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is a bit of an advanced topic, but seeing as the GitHub lessons already teach forking and CI, I think it might be helpful to have a callout about how Actions work in forks. That is, when a repository that has Actions set up is forked, all those actions are disabled in the fork. The fork owner can re-enable them through the Actions tab.
They are disabled by default for security: otherwise it would be dangerous to fork anything without deeply understanding that project's entire CI story. They are also disabled for correctness: often at least some workflows require secrets, which are of course not visible to the fork.
Often forking doesn't require turning Actions back on as on_pull_request jobs are jobs triggered by and run on the parent repo. But it can be confusing to fork owners why their project doesn't act the same. For example, they may want to adopt a branching git strategy within their fork and would like to see passing tests when merging two of their own branches. Also, the project may have actions triggered on things other than Pull Requests, and having those not trigger in forks can lead to divergent development behaviour.
The text was updated successfully, but these errors were encountered:
This is a bit of an advanced topic, but seeing as the GitHub lessons already teach forking and CI, I think it might be helpful to have a callout about how Actions work in forks. That is, when a repository that has Actions set up is forked, all those actions are disabled in the fork. The fork owner can re-enable them through the Actions tab.
They are disabled by default for security: otherwise it would be dangerous to fork anything without deeply understanding that project's entire CI story. They are also disabled for correctness: often at least some workflows require secrets, which are of course not visible to the fork.
Often forking doesn't require turning Actions back on as
on_pull_request
jobs are jobs triggered by and run on the parent repo. But it can be confusing to fork owners why their project doesn't act the same. For example, they may want to adopt a branching git strategy within their fork and would like to see passing tests when merging two of their own branches. Also, the project may have actions triggered on things other than Pull Requests, and having those not trigger in forks can lead to divergent development behaviour.The text was updated successfully, but these errors were encountered: