For example, do you remember the old times of complex caching techniques? Look at the solution for containers, where modern apps live.
stages: # List of stages for jobs, and their order of execution - build - test - deploy build-job: # This job runs in the build stage, which runs first. stage: build cache: key: build-cache paths: - cache script: - echo "Compiling the code..." >> cache/my.txt - cat cache/my.txt - echo "Compile complete."
If you don’t recognize how cool it is, there’s something you are missing! Really.
A question to check: what happens when you run the second pipeline? What’s the output?
Successfully extracted cache Executing "step_script" stage of the job script 00:01 Using docker image sha256:27d0... for ruby:2.5 with digest ruby@sha256:ecc3e...4b ... $ echo "Compiling the code..." >> cache/my.txt $ cat cache/my.txt Compiling the code... Compiling the code...
Yeah, the above, exactly: the line’s doubled since it’s cached.
Ok, fine, but you’ll object: it doesn’t work for me, because you may want to separate the upload and the download phases in possibly different pipelines.
No worries: e.g. you can use azure blob upload or download, again the main idea is that you’ll simply define the corresponding microsoft image in a cool yaml to enable your client sdk.
And that’s all folks