-
Notifications
You must be signed in to change notification settings - Fork 40
Multiple CI jobs for PRs #1173
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
Multiple CI jobs for PRs #1173
Conversation
| ~/.sbt | ||
| ~/.cache/coursier | ||
| key: effekt-build-${{ github.sha }} | ||
| fail-on-cache-miss: true |
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.
Great question: the cache here is a bit misleading, the whole point is to allow multi-machine builds by packaging up the build env after building and then restoring it just before calling sbt testWhatever in order to prevent recompiling
|
|
||
| on: | ||
| pull_request: | ||
|
|
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.
One thing we could consider is adding a concurrency group and cancel running jobs when a new commit is pushed:
concurrency:
group: ci-pr-${{ github.workflow }}-${{ github.head_ref || github.ref }}
cancel-in-progress: true
This saves CI minutes but has the disadvantage that some commits may not be tested and situations can arise where one has to wait longer for any CI feedback (in case of frequent pushes).
timsueberkrueb
left a comment
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.
Thank you, this will improve our developer experience a lot!
Trying to speed-up CI by having multiple jobs: total time goes from some 20-30 minutes down to 12!