-
Notifications
You must be signed in to change notification settings - Fork 42
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
Improve Github workflow #85
base: main
Are you sure you want to change the base?
Conversation
- Update `pull_request` triggers types to only ones which correspond to code changes; - Extract jobs from `default.yml` workflow to re-usable `test.yml` to be able to split default workflow to two workflow with different set of triggers - "schedule" and "pull_request/push"
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.
LGTM 👍
# Conflicts: # .github/workflows/default.yml
In the context of this PR, we can also add a feature to cancel the currently running job or workflow in the same concurrency group. https://docs.github.com/en/actions/writing-workflows/workflow-syntax-for-github-actions#concurrency |
After 60 days of inactivity workflows with
schedule
trigger will be disabled by Github https://docs.github.com/en/actions/writing-workflows/choosing-when-your-workflow-runs/events-that-trigger-workflows#schedule. As it turns out, this workflow also will not be triggered bypull_request
/push
triggers which is not ideal. We can mitigate that by creating re-usable workflow and call it from two different workflows on triggered onschedule
and another one triggered onpull_request
/push
.Change list
pull_request
triggers types to only ones which correspond to code changes;default.yml
workflow to re-usabletest.yml
to be able to split default workflow to two workflow with different set of triggers - "schedule" and "pull_request/push"Do not delete this PR branch untill #86 is merged to main