-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
[MBL-773] CircleCI Workspaces Integration #1821
Conversation
Codecov Report
@@ Coverage Diff @@
## main #1821 +/- ##
=======================================
Coverage 84.45% 84.45%
=======================================
Files 1283 1283
Lines 116650 116650
Branches 30953 30953
=======================================
Hits 98521 98521
Misses 17052 17052
Partials 1077 1077 📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more |
…require login, cleaned up comments in the config.yml
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.
awesome improvement!
@scottkicks I know you already approved this, but I just compared two workflows using the old config file and the newer. If you could take a look at |
📲 What and 🤔 Why
So our CI pipeline has a lot of repeated steps in it:
Example all of these steps run for every test job (that's 3x for kickstarter-framework-ios, ksapi, library)
Because these steps are run in parallel, they really don't blow up the time it takes for our suite to finish (approx. 30 min)
However why not run all the steps once, incorporate the environment they ran in (for example all the gems from bundle install) and re-use that environment for our test jobs.
Workspaces allows us to do this.
🛠 How
Workspaces has two steps essentially:
a
persist_to_workspace
step andattach_workspace
step.for our
test_job
anddistribute_job
weattach_workspace
. Thebuild_and_cache
step haspersist_to_a_workspace
step and sets up the environment with gems, swift package dependencies and the code itself.🏎 Performance
Side-by-side comparison of reduction in time.
Note the tests do not run until the build and cache step completes.
We might be expected it to be much faster but these jobs were run while CircleCI was in "maintenance" mode, so that probably effected the total time. Let's try this idea for now, and judge its' efficiency after we get some builds distributed.
In theory it "should" improve total time to build, but we need CI to be out of maintenance mode to see the real results.
Noted for posterity
Quick smoke test for new ci build time vs old build time (2 suites running same on conditions in CircleCI):
top workflow is using workspaces, bottom workflow using caching.
Caching is faster for total time taken
Pros:
Cons:
config.yml
file, less maintainable.prelaunch-simulator
commands.Workspaces is faster for individual test suites
Pros:
config.yml
file, all downloads/config/gems/code/packages done inbuild and cache
. Test job and distribute job just use the workspace.Cons:
build and cache
takes 10 min longer and runs first, before test suites. Bottleneck isbuild-and-cache
time + longest test suite time.✅ Acceptance criteria
⏰ TODO