-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ci to update all literature monthly #134
Conversation
✅ Deploy Preview for strchive ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
.github/workflows/update-loci.yaml
Outdated
snakemake --config stages="new-refs" | ||
|
||
- name: Update all literature (long) | ||
if: ${{ github.event_name == 'schedule' || github.event_name == 'workflow_dispatch'}} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So the long and intermediate steps will both run on workflow dispatches? Just checking that this is what you intended.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The reason I made this comment originally is because, the way they're named "short intermediate long", I would expect them to be mutually exclusive, i.e. only one of them runs each workflow run. But I haven't looked inside the scripts to see what's actually going on yet, is that actually the case? It doesn't have to be; I'd just recommend removing the lengths from the names if not.
Looks like now there's a clear split/association between the three trigger types (pr, schedule, manual) and the three script lengths (short, intermediate, long). Note that schedule and manual will also trigger PR on subsequent commits. Here's a breakdown of the scenarios (in terms of automatic workflow runs):
- Someone commits to
main
→ nothing happens - Someone manually creates a PR → someone commits →
pull_request
triggers, "short" script runs → updated data committed to PR - Someone manually runs
workflow_dispatch
→ "intermediate" script runs → PR opened with first commit of updated data → someone commits again to opened PR →pull_request
triggers → "short" script runs → updated data committed to PR schedule
runs once a month → "long" script runs → PR opened with first commit of updated data → someone commits again to opened PR →pull_request
triggers → "short" script runs → updated data committed to PR
If that looks okay, then the PR LGTM
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for breaking that down!
Yes, I think that is the desired behavior. Let's see if that all works out in practice.
Thanks for the feedback @vincerubinetti. Does this look better? |
.github/workflows/update-loci.yaml
Outdated
- name: Open pull request with updated files | ||
if: ${{ !(github.event_name == 'pull_request') }} | ||
if: ${{ !(github.event_name == 'pull_request') || github.event_name == 'schedule' }} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This "or schedule" is also unnecessary as it will already be covered by "not pull request"
This updates all citations monthly using GitHub Actions. I'm not sure if I have the logic of the triggers correct here.
Will resolve #59