ok, so this is a weird one...
I am using GitLab for pipeline management, the usual reasons, it's a system I have inherited, so lots of stuff done before my time... We have noticed that when we merge the development branch to master it triggers a build. When that build finishes it triggers a "Merge Master with Development" merge request, and we don't know why.
Has anyone else come across this before or know where this trigger might be based?
I had a look in the repo settings but can't see anything in WebHooks, the settings themselves or CD/CI settings.
Here is my .gitlab-ci.yml
image: alpine:3.10
variables:
GIT_STRATEGY: clone
cache: &global_cache
key: ${CI_COMMIT_REF_SLUG}
paths:
- node_modules/
policy: pull-push
before_script:
- apk update
- apk add openssh-client
- apk -Uuv add groff less python3 py-pip bash git curl gcc python3-dev musl-dev
- export PYTHONPATH=/usr/lib/python3.7
- alias pip=pip3
- alias python3=python
- pip install awscli
stages:
- deploy
- trigger
sonarcloud-check:
stage: deploy
allow_failure: true
image: openjdk:17-jdk-slim
variables:
SONAR_USER_HOME: "${CI_PROJECT_DIR}/.sonar"
SONAR_TOKEN: "${CI_SONAR_TOKEN}
SONAR_HOST_URL: "${CI_SONAR_HOST_URL}
cache:
key: "${CI_JOB_NAME}"
paths:
- .sonar/cache
before_script:
- apt-get update && apt-get install -y wget unzip curl git
- wget -qO /tmp/sonar-scanner.zip "https://binaries.sonarsource.com/Distribution/sonar-scanner-cli/sonar-scanner-cli-5.0.1.3006-linux.zip"
- unzip /tmp/sonar-scanner.zip -d /opt
- mv /opt/sonar-scanner-* /opt/sonar-scanner
- export PATH="/opt/sonar-scanner/bin:$PATH"
script:
- sonar-scanner -Dsonar.host.url=$SONAR_HOST_URL -Dsonar.token=$SONAR_TOKEN
only:
- merge_requests
- development
review:
stage: deploy
environment:
name: review/$CI_COMMIT_REF_NAME
url: http://REDACTED/$CI_COMMIT_REF_NAME/sitemap.html
variables:
REDACTED
script:
- apk add nodejs-npm
- npm ci
- >
if [ "$RUN_CMS_ONLY" == "true" ]; then
npm run clean
aws s3 sync --acl public-read ./build/ s3://REDACTED-review/$CI_COMMIT_REF_NAME/
else
npm run build
aws s3 sync --delete --acl public-read ./build/ s3://REDACTED-review/$CI_COMMIT_REF_NAME/
fi
except:
- development
- master
cache:
<<: *global_cache
policy: pull
artifacts:
paths:
- build/
development:
stage: deploy
environment:
name: development
url: http://REDACTED/sitemap.html
variables:
REDACTED
script:
- apk add nodejs-npm
- npm ci
- >
if [ "$RUN_CMS_ONLY" == "true" ]; then
npm run clean
aws s3 sync --acl public-read ./build/ s3://REDACTED-develop
else
npm run build
aws s3 sync --delete --acl public-read ./build/ s3://REDACTED-develop
fi
only:
- development
artifacts:
paths:
- build/
production1:
stage: deploy
environment:
name: production1
url: https://REDACTED/sitemap.html
variables:
REDACTED
script:
- apk add nodejs-npm
- REDACTED
- npm ci
- >
if [ "$RUN_CMS_ONLY" == "true" ]; then
npm run clean
aws s3 sync --acl public-read ./build/ s3://REDACTED-prod1
else
npm run build
aws s3 sync --delete --acl public-read ./build/ s3://REDACTED-prod1
fi
only:
- master
cache:
<<: *global_cache
policy: pull
artifacts:
paths:
- build/
npm_templates:
image: node:14-alpine
variables:
NPM_TOKEN: $CI_JOB_TOKEN
stage: trigger
script:
- |
{
echo "@${CI_PROJECT_ROOT_NAMESPACE}:registry=${CI_API_V4_URL}/projects/${CI_PROJECT_ID}/packages/npm/"
echo "${CI_API_V4_URL#http*:}/projects/${CI_PROJECT_ID}/packages/npm/:_authToken=\${CI_JOB_TOKEN}"
} >> .npmrc
- >
if [ "$RUN_CMS_ONLY" == "true" ]; then
echo "do not run npm templates on cms build"
else
npm i no-dependencies -g
no-dependencies --before
npm i @semantic-release/gitlab@6.2.0
npx semantic-release@16.0.4
curl --request POST --form "token=$PREVIEW_TRIGGER_TOKEN" --form ref=${CI_COMMIT_REF_NAME} https://gitlab.com/api/v4/projects/REDACTED/trigger/pipeline
fi
only:
refs:
- master
- development
changes:
- REDACTED
cache:
<<: *global_cache
policy: pull
Is seems that you're using semantic-release NPM package, most likely to generate changelogs, version tags and whatnot. Since default behaviour of this package is to commit and push its changes (new changelogs, tags, etc) to Gitlab, this creates a new commit on the master branch.
This effectively means that after your development has been merged into master, the pipeline triggered by that merge commit on master creates ANOTHER commit (i.e. semantic-release does that when npm-templates job is executed), and your master branch is now one commit ahead of development. The curl call at the end of the npm-templates job's script section is most likely used to open an MR from master to development to make sure that whatever has been committed by semantic-release to master is also available in the development branch.