resources:
builds:
- build: Spaceworkz
type: Jenkins
connection: MyJenkinsServer
source: SpaceworkzProj # name of the jenkins source project
trigger: true
Then, I use downloadBuild step.
How can I later in the pipeline get the version number of this build? It will be "latest" but I need the version number.
I can't see anything in doc.
Related
I am very new in Azure Devops. All my repositories are in BitBucket. I have one project say A which has dependency in project B
In Visual Studio there are no build errors, but when I am building the CI pipeline for A I am getting an error saying "Project B not found"
The CI pipeline is created with repository of project A. How can I solve this?
Note: I am using dev.azure.com and selected "Use classic editor to create a pipeline without YAML" so I am not able to add yaml code. Can you please tell me how to do this?
Sounds like you need to check out multiple repositories in your pipeline for example like this:
resources:
repositories:
- repository: MyBitbucketRepoA
type: bitbucket
endpoint: MyBitbucketServiceConnection
name: MyBitbucketOrgOrUser/MyBitbucketRepoA
- repository: MyBitbucketRepoB
type: bitbucket
endpoint: MyBitbucketServiceConnection
name: MyBitbucketOrgOrUser/MyBitbucketRepoB
steps:
- checkout: self
- checkout: MyBitbucketRepoA
- checkout: MyBitbucketRepoB
I need to update a couple of pipelines to use the same logic and thought about using templates to split the common YAML steps.
All the projects share the same dependency with an in-house Nuget package that is used for deployment. My initial idea is to use that package to hold the template YAML and reference it on each project but when I read the documentation I am not entirely sure this is supported.
To give you a better idea I'm going to exemplify with the same sample code on the documentation.
This would be our YAML in the Nuget package, to be inserted as a template reference on each project.
# File: templates/include-npm-steps.yml
steps:
- script: npm install
- script: yarn install
- script: npm run compile
This would be the YAML on each project that needed to consume the above YAML from the Nuget package.
# File: azure-pipelines.yml
jobs:
- job: Linux
pool:
vmImage: 'ubuntu-latest'
steps:
- template: templates/include-npm-steps.yml # Template reference
- job: Windows
pool:
vmImage: 'windows-latest'
steps:
- template: templates/include-npm-steps.yml # Template reference
Probably at run time the pipeline checks for the referenced templates and won't run since they need to be restored first. Any ideas?
As suspected you cannot consume a YAML in a Nuget package but have to reference the YAML from a repo instead.
I have a two projects in GitLab and I am trying to integrate SonarQube with my GitLab projects.
Project 1
I have added the 'sonar-scanner.properties' file to Project1 and it's as follows:
sonar-scanner.properties
# SonarQube server
# sonar.host.url & sonar.login are set by the Scanner CLI.
# See https://docs.sonarqube.org/latest/analysis/gitlab-cicd/.
# Project settings.
sonar.projectKey=Trojanwall
sonar.projectName=Trojanwall
sonar.projectDescription=My new interesting project.
sonar.links.ci=https://gitlab.com/rmesi/trojanwallg2-testing/-/pipelines
#sonar.links.issue=https://gitlab.com/rmesi/trojanwallg2-testing/
# Scan settings.
sonar.projectBaseDir=./
#sonar.sources=./
sonar.sources=./
sonar.sourceEncoding=UTF-8
sonar.host.url=http://sonarqube.southeastasia.cloudapp.azure.com:31000
sonar.login=4f4cbabd17914579beb605c3352349229b4fd57b
#sonar.exclusions=,**/coverage/**
# Fail CI pipeline if Sonar fails.
sonar.qualitygate.wait=true
Then I added the sonar scanner job in the gitlab-ci.yml file:
gitlab-ci.yml
sonar-scanner-trojanwall:
stage: sonarqube:scan
image:
name: sonarsource/sonar-scanner-cli:4.5
entrypoint: [""]
variables:
# Defines the location of the analysis task cache
SONAR_USER_HOME: "${CI_PROJECT_DIR}/.sonar"
# Shallow cloning needs to be disabled.
# See https://docs.sonarqube.org/latest/analysis/gitlab-cicd/.
GIT_DEPTH: 0
cache:
key: "${CI_JOB_NAME}"
paths:
- .sonar/cache
script:
- sonar-scanner
only:
- Production
- /^[\d]+\.[\d]+\.1$/
when: on_success
After this, I configured the two variables: 'SONAR_HOST_URL' and 'SONAR_TOKEN' and then, ran the pipeline. It worked perfectly fine for the Project 1.
Project 2
Then, I needed to do the same for the Project 2 as well. I needed the sonar scanner to go into the Project 2, scan and analyze. For that, I created another project in SonarQube with a new token.
I needed to configure in such a way that when the pipeline for Project 1 is triggered, it scans both Project 1 and 2.
For that, I added another job in Project1's pipeline.
It's as follows:
gitlab-ci.yml
sonar-scanner-test-repo:
stage: sonarqube:scan
trigger:
include:
- project: 'rmesi/test-repo'
ref: master
file: 'sonarscanner.gitlab-ci.yml'
only:
- Production
- /^[\d]+\.[\d]+\.1$/
when: on_success
I tried to setup a downstream pipeline to trigger a yaml file in Project 2. So, when The pipeline in Project 1 is triggered and when the job 'sonar-scanner-test-repo' gets triggered, another yaml file in Project 2 is run as a down stream pipeline. That YAML file is as follows:
sonarscanner.gitlab-ci.yml
stages:
- sonarqube:scan
variables:
CI_PROJECT_DIR: /builds/rmesi/test-repo
sonar-scanner:
stage: sonarqube:scan
image:
name: sonarsource/sonar-scanner-cli:4.5
entrypoint: [""]
variables:
# Defines the location of the analysis task cache
SONAR_USER_HOME: "${CI_PROJECT_DIR}/.sonar"
# Shallow cloning needs to be disabled.
# See https://docs.sonarqube.org/latest/analysis/gitlab-cicd/.
GIT_DEPTH: 0
cache:
key: "${CI_JOB_NAME}"
paths:
- .sonar/cache
script:
- cd /builds/rmesi/
- git clone https://gitlab.com/rmesi/test-repo.git test-repo
- sonar-scanner
Then I added the 'sonar-project.properties' file in Project2 which is as follows:
sonar-project.properties
# SonarQube server
# sonar.host.url & sonar.login are set by the Scanner CLI.
# See https://docs.sonarqube.org/latest/analysis/gitlab-cicd/.
# Project settings.
sonar.projectKey=test-repo
sonar.projectName=test-repo
sonar.projectDescription=My new interesting project.
sonar.links.ci=https://gitlab.com/rmesi/test-repo/-/pipelines
#sonar.links.issue=https://gitlab.com/rmesi/test-repo/
# Scan settings.
sonar.projectBaseDir=/builds/rmesi/test-repo/
sonar.sources=/builds/rmesi/test-repo/, ./
sonar.sourceEncoding=UTF-8
sonar.host.url=http://sonarqube.southeastasia.cloudapp.azure.com:31000
sonar.login=b0c40e44fd59155d27ee43ae375b9ad7bf39bbdb
#sonar.exclusions=,**/coverage/**
# Fail CI pipeline if Sonar fails.
sonar.qualitygate.wait=true
The issue is that, when the down stream pipeline is run, I am getting the following error message:
I figured out that the down stream pipeline is not locating the 'sonar-scanner.properties' in Project 2. (Lines 68 and 74)
Where as, on Project 1 while searching for this step, it shows:
INFO: Project root configuration file: /builds/rmesi/trojanwallg2-testing/sonar-project.properties
But in Project 2 it's not working.
Does anyone know how to fix this?
I found the solution to this, myself.
Required to add
"- cd /build/rmesi/test-repo ; sonar-scanner"
in the script section in the job of the 'sonarscanner.gitlab-ci.yml' file.
That way, the runner maps directly to desired directory and execute the 'sonar-scanner' command there.
I have a CI pipeline in Bitbucket which is used to build and test a shared Node.js library. If we create tag (eg. npm version patch -m "Upgrade to 0.1.2 for bug fix") the new version must be published to the npm repository.
Therefore I have the following pipeline configuration:
pipelines:
default:
- step: *build-test-sonarcloud
tags:
'*':
- step: *build-test-sonarcloud
- step: *build-deploy-npm
However, if I push all changes after 'npm version patch' two pipelines are started. I suppose that this is because the file 'package.json' is also committed and not only a tag.
My idea is that only the 'tags'-pipeline should be started in case of a commit of a tag (with or without any files). Is there a way to only trigger that pipeline and prevent the default pipeline to run?
When you mention '*' after tags step, this means, the pipeline will be running twice every time.
You need to mention tag name, something like below code
pipelines:
default:
- step: *build-test-sonarcloud
tags:
'yourCustomTagName':
- step: *build-test-sonarcloud
- step: *build-deploy-npm
Now whenever you push your code with yourCustomTagName, then both the steps will run in the pipeline, if not only one will run.
When I take a mergeRequest in GitLab, there is a compile error with description:
CI build failed for 4a0b9b43 , view Details：.gitlab-ci.yml not
found in this commit.
But I have sync with the destination branch and compile succeed on native, how can I fix this issue?
You must place the .gitlab-ci.yml file to the root directory of a project first. If you want to cross-reference other CI configuration locally or from somewhere (GitLab instance required to install on remote locations), you must use the include tag
How-to
Please check your GL instance version first before you are using include. Compare your instance version with the minimum version required from the documentation. If you need to upgrade, back up everything and run an update. It should take hours before you can go back into business.
To cross-reference CI config files locally, use the include:local. Make sure they are on the same branch. If that is on other branch, use ref.
include:
- local: '/templates/.gitlab-ci-template.yml'
In case you want to cross-reference CI config files somewhere within the instance, use
include:
- project: 'my-group/my-project'
file: '/templates/.gitlab-ci-template.yml'
# You can also specify ref, with the default being the head of the object.
- project: 'my-group/my-project'
ref: master # Git branch
file: '/templates/.gitlab-ci-template.yml'
- project: 'my-group/my-project'
ref: v1.0.0 # Git tag
file: '/templates/.gitlab-ci-template.yml'
- project: 'my-group/my-project'
ref: 787123b47f14b552955ca2786bc9542ae66fee5b # Git SHA
file: '/templates/.gitlab-ci-template.yml'
If you prefer to use CI config templates shipped with the instance, use include:template. Check the GitLab's template collection for more details.
include:
- template: Auto-DevOps.gitlab-ci.yml
If deployed outside the instance borders, like GitLab.com, use include:remote.
include:
- remote: 'https://gitlab.com/awesome-project/raw/master/.gitlab-ci-template.yml'
Examples
The first example was derived from GitLab's CI config file for GitLab EE (gitlab-org/gitlab).
image: "registry.gitlab.com/gitlab-org/gitlab-build-images:ruby-2.6.3-golang-1.12-git-2.24-lfs-2.9-chrome-73.0-node-12.x-yarn-1.16-postgresql-9.6-graphicsmagick-1.3.33"
stages:
- sync
- prepare
- quick-test
- test
- post-test
- review-prepare
- review
- qa
- post-qa
- notification
- pages
variables:
RAILS_ENV: "test"
NODE_ENV: "test"
SIMPLECOV: "true"
GIT_DEPTH: "20"
GIT_SUBMODULE_STRATEGY: "none"
GET_SOURCES_ATTEMPTS: "3"
KNAPSACK_RSPEC_SUITE_REPORT_PATH: knapsack/report-master.json
FLAKY_RSPEC_SUITE_REPORT_PATH: rspec_flaky/report-suite.json
BUILD_ASSETS_IMAGE: "false"
ES_JAVA_OPTS: "-Xms256m -Xmx256m"
ELASTIC_URL: "http://elastic:changeme#elasticsearch:9200"
after_script:
- date
include:
- local: .gitlab/ci/cache-repo.gitlab-ci.yml
- local: .gitlab/ci/cng.gitlab-ci.yml
- local: .gitlab/ci/docs.gitlab-ci.yml
- local: .gitlab/ci/frontend.gitlab-ci.yml
- local: .gitlab/ci/global.gitlab-ci.yml
- local: .gitlab/ci/memory.gitlab-ci.yml
- local: .gitlab/ci/notifications.gitlab-ci.yml
- local: .gitlab/ci/pages.gitlab-ci.yml
- local: .gitlab/ci/qa.gitlab-ci.yml
- local: .gitlab/ci/reports.gitlab-ci.yml
- local: .gitlab/ci/rails.gitlab-ci.yml
- local: .gitlab/ci/review.gitlab-ci.yml
- local: .gitlab/ci/setup.gitlab-ci.yml
- local: .gitlab/ci/dev-fixtures.gitlab-ci.yml
- local: .gitlab/ci/test-metadata.gitlab-ci.yml
- local: .gitlab/ci/yaml.gitlab-ci.yml
- local: .gitlab/ci/releases.gitlab-ci.yml
You can see more examples on the .gitlab-ci.yml reference in the GitLab documentation.