Optimize build_instrumented job#6954
Conversation
build_instrumented job
8399748 to
bd27a16
Compare
bd27a16 to
7c988d1
Compare
| paths: | ||
| - ~/.gradle/caches/modules-2/files-2.1 | ||
| key: compile-deps-{{ checksum "deps.txt" }} | ||
| - ~/work |
There was a problem hiding this comment.
Interestingly, saving to cache is much faster than persisting to workspace for large sets of files. Caching makes more sense here as well as we don't need the files we're saving here: they just help speed subsequent jobs in the worklow up.
| root: ~/work | ||
| paths: | ||
| - . | ||
| - collect_app/build/outputs/apk |
There was a problem hiding this comment.
We still need to save the APK so that it can be definitely available to the Test Lab jobs.
| ./check-size.sh 23117869 | ||
| else | ||
| ./check-size.sh 13785543 | ||
| ./check-size.sh 13841204 |
There was a problem hiding this comment.
Not sure why this increase? It's a very small bump though.
| commit: | ||
| jobs: | ||
| - compile | ||
| - hold_pr: |
There was a problem hiding this comment.
I often find that I might be committing/pushing quickly and that context, CI will be constantly starting and cancelling workflow runs. Add a manual approval step means we only end up running jobs when we actually care about the result. I'd like to try this, but definitely let me know if you feel like it's getting annoying @grzesiek2010.
There was a problem hiding this comment.
I agree with your rationale, but isn’t it possible to differentiate between draft and ready-for-review PRs and trigger jobs only for those that are ready for review?
There was a problem hiding this comment.
Good idea! It looks like this might be possible with the new Github triggers, but I'm not sure that we'd be able to have it always run for non-drafts and optionally for drafts (you still probably want CI on request for drafts). We could always just use the GitHub API (probably through gh).
I think that's probably a future improvement though: I think we either go with the basic version as-is or remove the hold_pr check for now.
| branches: | ||
| only: | ||
| - master | ||
| - compile: |
There was a problem hiding this comment.
Is it possible to have two jobs with the same name (compile)? Does it work or one replaces the other?
There was a problem hiding this comment.
They both reference the compile job definition - this isn't declaring the job. One runs on master only and the other only on non-master.
This fixes the
build_instrumentedstep by giving it a larger resource and better suited memory config. I've also done some general touch ups on caching etc and added manual approval to PR CI runs. I'm hoping all of this increases CI run time and stability without massively increasing costs.