Remove hard-coded organization in website build action#157
Remove hard-coded organization in website build action#157Gee307 wants to merge 1 commit intoneuroinformatics-unit:mainfrom
Conversation
| linting: | ||
| # scheduled workflows should not run on forks | ||
| if: (${{ github.event_name == 'schedule' }} && ${{ github.repository_owner == 'neuroinformatics-unit' }} && ${{ github.ref == 'refs/heads/main' }}) || (${{ github.event_name != 'schedule' }}) | ||
| if: github.event_name != 'schedule' || github.ref == 'refs/heads/main' |
There was a problem hiding this comment.
Does this stop the workflow from running on forks? A fork will still have a main branch.
There was a problem hiding this comment.
To avoid hard-coding the org, we could check something fork-specific (e.g.!github.event.repository.fork) rather than the owner name.
|
Thanks for this @Gee307. However, I noticed that the changes were in the wrong place. There are two sets of github workflows:
I think those at the top are fine as they are, but the ones within the built package shouldn't have a reference to our org (see original issue (#125)). I think the easiest way to solve this is just to remove the fork check for scheduled jobs within the package. If users of this package want to remove the scheduled job, they can do. Hope this make sense! |
3 participants
Description
What is this PR
Why is this PR needed?
This repository is a cookiecutter template, but the docs build workflow hard-codes the neuroinformatics-unit organization. This prevents scheduled workflows from running correctly for downstream users who generate projects from this template.
What does this PR do?
Removes the hard-coded organization check from the GitHub Actions condition and instead restricts scheduled runs to the main branch only. This preserves safety while making the workflow reusable for any repository owner.
References
Fixes #125
How has this PR been tested?
The change is limited to a GitHub Actions conditional. The logic was verified by inspecting the workflow condition and ensuring it behaves identically for non-scheduled events while enabling scheduled runs for downstream repositories.
Is this a breaking change?
No
Does this PR require an update to the documentation?
No
Checklist: