I really don't understand how cache works and how i can really speed up my CI/CD. I would like to just make it run in less than 2 minutes but all i got is a 30m/40m/1h pipeline.
I have already tried a lot of caching techniques (Global cache, per job cache)
I am not going to write all of them here (i am working on this 3 days by now so i tried a lot of stuff and read a lot of stuff too..).
The project is a .NET MVC Project with some static bundling through NPM.
The CI/CD is running on a Windows Server 2008 R2.
No docker images. Just gitlab-runner inside the C:\gitlab_runner folder and all the tools are natively installed on the machine tagged as deploy-vmdev
(The project is called Iom.Site and it is saved inside the Iom.Site folder)
The best i was able to do was this (but it runs on average of 30m and sometimes it breaks up because depedencies caches, node_modules and packages, aren't present.):
stages:
- install_dependencies
- build_app
- deploy
#Execute dependencies only on package-lock.json e packages.config changes
install_dependencies:
stage: install_dependencies
only:
changes:
- Iom.Site/package-lock.json
- Iom.Site/packages.config
cache:
key: ${CI_COMMIT_REF_SLUG}
paths:
- Iom.Site/node_modules
- packages/
tags:
- deploy-vmdev
script:
- if(!((nuget sources) -like "*Promoscience*").Length -gt 0) { nuget sources add -Name Promoscience -Source http://nupromo.promoscience.com/nuget };
- nuget restore
- cd Iom.Site
- npm install
#Bundling through gulp npm packages static files (SCSS, JS,..)
#Copying .\site\content inside .\dist folder at root for packaging
build_static_files:
stage: build_app
only:
changes:
- Iom.Site\scripts\bundle\**\*
- Iom.Site\scripts\react\**\*
- Iom.Site\scss\**\*
- ".gitlab-ci.yml"
cache:
key: ${CI_COMMIT_REF_SLUG}
paths:
- Iom.Site/node_modules
policy: pull
tags:
- deploy-vmdev
script:
- gulp build
- cd ..
- Copy-Item Iom.Site\content .\dist\
artifacts:
paths:
- .\dist
when: on_success
expire_in: 30 days
#Building .NET App through MSBUILD. Msbuild profile saves the output in .\dist folder
#for packaging the whole app
build_app:
stage: build_app
only:
changes:
- "**/*.cs"
- "**/*.cshtml"
- "**/*.config"
- ".gitlab-ci.yml"
tags:
- deploy-vmdev
script:
- msbuild Iom.Site\Iom.Site.csproj /p:Configuration=test /p:PublishProfile=FolderProfile /p:transformConfigFiles=true /p:deployOnBuild=true
cache:
key: ${CI_COMMIT_REF_SLUG}
paths:
- packages/
policy: pull
artifacts:
paths:
- .\dist
when: on_success
expire_in: 30 days
#Deploying: Downloading artifacts and merging them.
#Copying the content of dist folder inside the IIS Site
deploy_test:
stage: deploy
dependencies:
- build_static_files
- build_app
tags:
- deploy-vmdev
only:
- master
- dev
cache: {}
variables:
SiteAppPath: "E:\\websites\\CnrIom2020"
script:
- echo $env:SiteAppPath
- dir .\dist
- Copy-Item .\dist\* $env:SiteAppPath -Recurse -Force
UPDATE 1:
In the end i found this on gitlab ci wiki:
Caching is an optimization, but it isn’t guaranteed to always work. You need to be prepared to regenerate any cached files in each job that needs them.
And changed my pipeline in this way:
stages:
- build_app
- package
- deploy
build_static_files:
stage: build_app
before_script:
- cd Iom.Site
- if(-Not(Test-Path node_modules)){npm install} #Installiamo le dipendenze di npm solo se non presenti
only:
changes:
- Iom.Site\scripts\bundle\**\*
- Iom.Site\scripts\react\**\*
- Iom.Site\scss\**\*
- ".gitlab-ci.yml"
tags:
- deploy-vmdev
cache:
key: static_${CI_COMMIT_REF_SLUG}
paths:
- Iom.Site/node_modules
policy: pull-push
script:
- gulp build
- cd ..
- Copy-Item Iom.Site\content .\dist\content -Recurse -Force #Copiamo i file statici in dist
artifacts:
paths:
- .\dist
when: on_success
expire_in: 2 hours
build_app:
stage: build_app
before_script: #Installiamo le dipendenze di Nuget solo se già non presenti
- if(-Not(Test-Path packages)){ nuget restore }
only:
changes:
- "**/*.cs"
- "**/*.cshtml"
- "**/*.config"
- ".gitlab-ci.yml"
tags:
- deploy-vmdev
cache:
key: app_${CI_COMMIT_REF_SLUG}
paths:
- packages
policy: pull-push
script:
- msbuild Iom.Site\Iom.Site.csproj /p:Configuration=test /p:PublishProfile=FolderProfile /p:transformConfigFiles=true /p:deployOnBuild=true
artifacts:
paths:
- .\dist
when: on_success
expire_in: 2 hours
package_app:
stage: package
dependencies:
- build_static_files
- build_app
tags:
- deploy-vmdev
only:
- master
- dev
- release
cache: { }
script:
- dir .\dist
artifacts:
paths:
- .\dist
expire_in: never
deploy_test:
stage: deploy
dependencies:
- package_app
tags:
- deploy-vmdev
only: #TODO: When: manual
- master
- dev
- release
cache: {}
variables:
SiteAppPath: "E:\\websites\\CnrIom2020"
script:
- echo $env:SiteAppPath
- dir .\dist
- Copy-Item .\dist\* $env:SiteAppPath -Recurse -Force
# deploy_release: To define
Related
So I have a job which is triggered with specific rules - creating a new tag app-prod-1.0.0 or app-dev-1.0.0. Whenever new tag is created I call the job, which in return extends other jobs
image: node:lts-alpine
stages:
- install
- build
- deploy
.install-packages:
stage: install
script:
- echo "INSTALL-PACKAGES"
- yarn install --cache-folder .yarn-cache
artifacts:
paths:
- node_modules
cache:
- key:
files:
- yarn.lock
paths:
- .yarn-cache/
.build-project:
stage: build
script:
- echo "BUILD-PROJECT"
- echo $ENVIRONMENT
- yarn build
artifacts:
paths:
- build
.deploy-project:
stage: deploy
script:
- echo "DEPLOY-PROJECT"
- ls -la build
build_prod:
variables:
PACKAGE: '/app/prod'
ENVIRONMENT: 'prod'
extends:
- .install-packages
- .build-project
- .deploy-project
rules:
- if: '$CI_COMMIT_TAG =~ /^app-prod-[0-9]+\.[0-9]+\.[0-9]+$/'
build_dev:
variables:
PACKAGE: '/app/dev'
ENVIRONMENT: 'dev'
extends:
- .install-packages
- .build-project
- .deploy-project
rules:
- if: '$CI_COMMIT_TAG =~ /^app-dev-[0-9]+\.[0-9]+\.[0-9]+$/'
My thought was that jobs will be called in the order I have described inside the job: .install-packages, .build-project, .deploy-project. But that's not happening it seems that it just jumps to the last job .deploy-project, without installing and building and thus breaking my pipeline.
How to run/extend jobs in sequence?
This is the behaviour for which I didn't use multiple extends so far in my work with GitLab.
GitLab, attempts to merge the code from parent job.
Now all your parent jobs defines the script tag and in your job for e.g. build_prod the extends happening in below order
extends:
- .install-packages
- .build-project
- .deploy-project
the script code from .deploy-project is overwriting the other job's script tag.
It works differently for the variables. It will merge all the variables and overwrites if same variable is used.
See your own example updated with variables.
image: node:lts-alpine
stages:
- install
- build
- deploy
.install-packages:
stage: install
variables:
PACKAGE: 'install'
INSTALL: 'install'
script:
- echo "INSTALL-PACKAGES"
- yarn install --cache-folder .yarn-cache
artifacts:
paths:
- node_modules
cache:
- key:
files:
- yarn.lock
paths:
- .yarn-cache/
.build-project:
stage: build
variables:
PACKAGE: 'build'
BUILD: 'build'
script:
- echo "BUILD-PROJECT"
- echo $ENVIRONMENT
- yarn build
artifacts:
paths:
- build
.deploy-project:
stage: deploy
variables:
PACKAGE: 'deploy'
DEPLOY: 'from deploy'
script:
- echo "DEPLOY-PROJECT"
- ls -la build
build_prod:
variables:
PACKAGE: '/app/prod'
ENVIRONMENT: 'prod'
extends:
- .install-packages
- .build-project
- .deploy-project
rules:
- if: '$CI_COMMIT_TAG =~ /^app-prod-[0-9]+\.[0-9]+\.[0-9]+$/'
build_dev:
variables:
PACKAGE: '/app/dev'
ENVIRONMENT: 'dev'
extends:
- .install-packages
- .build-project
- .deploy-project
rules:
- if: '$CI_COMMIT_TAG =~ /^app-dev-[0-9]+\.[0-9]+\.[0-9]+$/'
And now notice how PACKAGE variable is overwritten with the final value of '/app/prod' which comes from build-prod job itself. At the same time other variables from individual parent jobs are merged to look like below
variables:
PACKAGE: "/app/prod"
INSTALL: install
BUILD: build
DEPLOY: from deploy
ENVIRONMENT: prod
I really found View merged YAML feature best to understand how my yml file will be evaluated.
Its available in CI/CD -> Editor
It's not actually "jumps to the last job", but simply executes a single job you have provided - that is build_prod or build_dev, depending on commit tag.
As per docs when you are calling extends, you are basically just merging everything inside all the template jobs that you specified, so the last stage keyword, which comes from .deploy-project template job wins.
You should specify each job separately for each stage, and maybe even put your rules to a separate template job, i.e.
.dev:
variables:
PACKAGE: '/app/dev'
ENVIRONMENT: 'dev'
rules:
- if: '$CI_COMMIT_TAG =~ /^app-dev-[0-9]+\.[0-9]+\.[0-9]+$/'
install-dev:
extends:
- .dev
- .install-packages
build-dev:
extends:
- .dev
- .build-project
deploy-dev:
extends:
- .dev
- .deploy-project
You should create similar jobs for prod env, define template job .prod, and create install-prod, build-prod, deploy-prod jobs
I am getting the error Not uploading cache {name of branch} due to policy in my gitlab runner. My .yaml file looks like this:
stages:
- test
- staging
- publish
- deploy
# cache using branch name
# https://gitlab.com/help/ci/caching/index.md
cache:
key: ${CI_COMMIT_REF_SLUG}
paths:
- .yarn
- node_modules/
policy: pull
before_script:
- yarn install --cache-folder .yarn
test:
stage: test
image: node:14
script:
- yarn install
- yarn test
pages:
stage: staging
image: alekzonder/puppeteer
except:
- master
script:
- yarn install
- yarn compile
- yarn build
publish:
stage: publish
image: alekzonder/puppeteer
when: manual
script:
- yarn install
- yarn compile
- yarn build
artifacts:
paths:
- dist
deploy:
image: google/cloud-sdk:latest
stage: deploy
needs:
- publish
script:
- gcloud auth activate-service-account --account ${GCP_SERVICE_ACCOUNT} --key-file ${GOOGLE_APPLICATION_CREDENTIALS}
- gsutil -u test rsync -r -d dist/ gs://test.ca
I was wondering why it always fails to upload, and thereby fails to extract the cache. Any tips or corrections welcome. Here is a screenshot of where it fails:
You have the following set:
cache:
key: ${CI_COMMIT_REF_SLUG}
paths:
- .yarn
- node_modules/
policy: pull
Which sets a pipeline-global precedent that you only want to (policy: pull) pull from the cache.
You'll want to read https://docs.gitlab.com/ee/ci/yaml/#cachepolicy
If you omit the policy: piece, the default is to pull-push (which will get your cache uploading).
I tend to have my pipelines structured a little different than yours, though. I typically have a "prep" step that I define, and then run the yarn install once there:
"Installing Dependencies":
image: node:lts
stage: Prep
cache:
paths:
- .yarn
- node_modules/
policy: pull-push
script:
yarn install
...
Note: Then you can leave your global policy of 'pull', since this one job will have an override to pull-push.
Then, you can remove the yarn install on all other tasks, as the cache will be restored.
I'm trying to set up the Bamboo build plan configuration using Bamboo YAML specs (.yml file below). In the last stage (Create deployment artifacts) I want to use the shared artifacts from the previous stage. By specifying the artifacts of the jobs as "shared: true" I can use them in the second stage. However, they are in the same destination folder. Using the UI this can be easily edited.
Artifact dependencies
But how can I specify the destination folder of the two artifacts in the Bamboo YAML specs, e.g. from "Root of working directory" to "./app" and "./wwwroot", respectively?
---
version: 2
plan:
project-key: COCKPIT
key: BE
name: Cockpit - Continuous Build - Windows
stages:
- Build Stage:
- Build Backend
- Build Frontend
- Build Artifact:
- Create Deployment Artifact
Build Backend:
requirements:
- Visual Studio Build Tools (32-bit)
tasks:
- checkout:
repository: cockpit_backend
path: 'cockpit_backend'
force-clean-build: false
- script:
- dotnet publish .\cockpit_backend\src\Cockpit.WebApi\ --configuration Release
artifacts:
-
name: BackendBuild
location: cockpit_backend/src/Cockpit.WebApi/bin/Release/netcoreapp3.1/publish
pattern: '**/*.*'
required: true
shared: true
Build Frontend:
requirements:
- os_linux
tasks:
- checkout:
repository: 'Cockpit / cockpit_frontend'
path: 'cockpit_frontend'
force-clean-build: false
- script:
- cd cockpit_frontend
- npm install
- script:
- cd cockpit_frontend
- npm run build-prod
docker:
image: node:alpine
artifacts:
-
name: FrontendBuild
location: cockpit_frontend/dist
pattern: '**/*.*'
required: true
shared: true
Create Deployment Artifact:
requirements:
- os_windows
tasks:
- script:
interpreter: powershell
scripts:
- $buildDir = "Cockpit"
- $dest = "Cockpit_${bamboo.buildNumber}.zip"
- Add-Type -assembly "system.io.compression.filesystem"
- '[io.compression.zipfile]::CreateFromDirectory($buildDir, $dest)'
artifacts:
-
name: Completebuild
pattern: 'Cockpit_${bamboo.buildNumber}.zip'
required: true
YAML specs doesn't support artifact dependency management and you need to have script task at "Create Deployment Artifact" job to put them into separate folders from root before compressing
I'm using GitLab CI.
I have 2 jobs in the build stage that build differently my app. The 2 jobs upload a cache for the branch. I use the compiled sources to launch some tests in the test stage.
build:
stage: build
script:
- ./gradlew build --build-cache --quiet
cache:
key: ${CI_COMMIT_REF_SLUG}
paths:
- "*/build"
build_with_different_conf:
stage: build
script:
- ./gradlew buildDiff --build-cache --quiet
cache:
key: ${CI_COMMIT_REF_SLUG}
paths:
- "*/build"
Test:
stage: test
script:
- ./gradlew test --build-cache
In my example, the job build_with_different_conf take more time to finish.
My question is : Is the last finishing build job upload the cache and replace the cache from the first build job or is it merging files whith the precedent job ?
Thanks.
From what i understand you are using global cache for gradle dependencies.
Than you want to have some kind of job, to job cache.
I would do it this way, more or less.
stages:
- build
- test
cache:
paths:
- <your_gradle_cache>
build_classes:
stage: build
script:
- ./gradlew build --build-cache --quiet
artifacts:
expire_in: 1d
paths:
- <your_build_dir>
build_war:
stage: build
dependencies:
- build_classes
script:
- ./gradlew buildDiff --build-cache --quiet
artifacts:
expire_in: 1w
paths:
- <path_to_your_war>
test_classes:
stage: test
dependencies:
- build_war
script:
- ./gradlew test --build-cache
test_war:
stage: test
dependencies:
- build_war
script:
- test # some kind of test to assure your war is in good condition
In this configuration:
build_classes --[.classes]--> build_war -> [.war]
| |
[.classes] [.war]
| |
V V
test_classes test_war
PS. Dont forget you can use shell (or whatever your runner's os) to debug, understand more about this. You can put ls -la all over the place.
build:
stage: build
Same stage jobs runs in parallel.
cache:
key: ${CI_COMMIT_REF_SLUG}
paths:
- "*/build"
Cache files are managed by cache:key. It means if you're using same cache:key for different jobs they'll share same cache.zip file across jobs even you're defining different cache:paths. If you're using same key, but different path then your cache won't be effective, because of every job will overwrite cache.zip file with different path contents.
In your case you're using same cache:key across different jobs.
cache:
key: ${CI_COMMIT_REF_SLUG}
paths:
- "*/build"
It means last finished job will overwrite the cache.zip file not merge and will be used for next job and subsequent pipeline jobs with same key defined.
Bonus:
Test:
stage: test
script:
- ./gradlew test --build-cache
Also beware that if this job requires */build directory contents to exist, you have to be careful and better to use artifacts instead. Cache doesn't always exist and it's provided as best effort delivery.
For example I use gitlab ci's cache like this.
nodejs_test:
stage: test
image: node:12.13-alpine
before_script:
- npm install
script:
- yarn test
cache:
key:
files:
# New cache key will be computed on each package.json change.
- package.json
paths:
- node_modules/
nodejs_build:
stage: build
image: node:12.13-alpine
before_script:
# In case if we miss cache, we can simply install packages again.
# If cache is there npm install won't download them again.
- npm install
script:
- yarn build
cache:
policy: pull # totally optional
key:
files:
- package.json
prefix: ${CI_COMMIT_REF_SLUG}
paths:
- node_modules/
everyone. I need some help with some issues that I am facing configuring circleCi for my Angular project.
The config.yml that I am using for a build and deploy process is detailed below. Currently I have decided to do separate jobs for each environment and each one includes the building and deploy. The problem with this approach is that I am repeating myself and I can't find the correct way to deploy an artifact builded in the previous job for the same workflow.
version: 2
jobs:
build:
docker:
- image: circleci/node:8-browsers
steps:
- checkout
- restore_cache:
key: dependency-cache-{{ checksum "package.json" }}
- run:
name: Install dependencies
command: npm install
- save_cache:
key: dependency-cache-{{ checksum "package.json" }}
paths:
- .node_modules
- run:
name: Build Application (Production mode - aot enabled)
command: npm run build:prod
- store_artifacts:
path: dist
destination: dist
deploy_prod:
docker:
- image: circleci/node:8-browsers
environment:
- FIREBASE_TOKEN: "1/AFF2414141ASdASDAKDA4141421sxscq"
steps:
- checkout
- restore_cache:
key: dependency-cache-{{ checksum "package.json" }}
- run:
name: Install dependencies
command: npm install
- save_cache:
key: dependency-cache-{{ checksum "package.json" }}
paths:
- .node_modules
- run:
name: Build Application (Production mode - aot enabled)
command: npm run build:prod
- store_artifacts:
path: dist
destination: dist
- run:
command: ./node_modules/.bin/firebase use default
- deploy:
command: ./node_modules/.bin/firebase deploy --token=$FIREBASE_TOKEN
deploy_qa:
docker:
- image: circleci/node:8-browsers
environment:
- FIREBASE_TOKEN: "1/AFF2414141ASdASDAKDA4141421sxscq"
steps:
- checkout
- restore_cache:
key: dependency-cache-{{ checksum "package.json" }}
- run:
name: Install dependencies
command: npm install
- save_cache:
key: dependency-cache-{{ checksum "package.json" }}
paths:
- .node_modules
- run:
name: Build Application (Production mode - aot enabled)
command: npm run build:prod
- store_artifacts:
path: dist
destination: dist
- run:
command: ./node_modules/.bin/firebase use qa
- deploy:
command: ./node_modules/.bin/firebase deploy --token=$FIREBASE_TOKEN
workflows:
version: 2
build-and-deploy:
jobs:
- build:
filters:
branches:
only:
- master
ignore:
- /feat-.*/
- deploy_prod:
filters:
branches:
ignore:
- /.*/
tags:
only:
- /v[0-9]+(\.[0-9]+){2}/
- deploy_qa:
filters:
branches:
ignore:
- /.*/
tags:
only:
- /v[0-9]+(\.[0-9]+){2}-BETA-([0-9]*)/
I understand that each job is using a different docker image, so this prevents me work on the same workspace.
Q: How can I use the same docker image for different jobs in the same workflow?
I included the store_artifacts thinking it could help me, but what I read about it is that it only works for using through the dashboard or the API.
Q: Am I able to recover an artifact on a job that requires a different job that stored the artifact?
I know that I am repeating myself, my goal is to have a build job required for a deploy job per environment depending on the tags' name. So my deploy_{env} jobs are mainly the firebase commands.
workflows:
version: 2
build-and-deploy:
jobs:
- build:
filters:
branches:
only:
- master
ignore:
- /feat-.*/
tags:
only:
- /v[0-9]+(\.[0-9]+){2}/
- /v[0-9]+(\.[0-9]+){2}-BETA-([0-9]*)/
- deploy_prod:
requires:
- build
filters:
branches:
ignore:
- /.*/
tags:
only:
- /v[0-9]+(\.[0-9]+){2}/
- deploy_qa:
requires:
- build
filters:
branches:
ignore:
- /.*/
tags:
only:
- /v[0-9]+(\.[0-9]+){2}-BETA-([0-9]*)/
Q: What are the recommended steps (best practices) for this solution?
Q: How can I use the same docker image for different jobs in the same workflow?
There might be two methods of going about this:
1.) Docker Layer Caching: https://circleci.com/docs/2.0/docker-layer-caching/
2.) Caching the .tar file: https://circleci.com/blog/how-to-build-a-docker-image-on-circleci-2-0/
Q: Am I able to recover an artifact on a job that requires a different
job that stored the artifact?
The persist_to_workspace and attach_workspace keys should be helpful here: https://circleci.com/docs/2.0/workflows/#using-workspaces-to-share-data-among-jobs
Q: What are the recommended steps (best practices) for this solution?
Not sure here! Whatever works the fastest and cleanest for you. :)