I have repository in GitLab. and I have Test and Dev branches in this repository.
In Gitlab pipeline, I schedule a job to auto run Test branch pipeline every 24 hours.
in Test .gitlab-ci.yml I have
deploy:
stage: deploy
script:
- git pull --ff-only origin Dev
only:
- Test
After merging Dev in Test, this part of code was removed. And next time Test branch pipeline could not pull from Dev branch, when pipeline run.
How can I pull code from Dev branch to Test Branch without losing the code - git pull --ff-only origin Dev ?
Or maybe it is possible to have tow .gitlab-ci.yml on branch? (if yes, how GitLab should know which one of them be diploid first? )
Or maybe it is possible to have two .gitlab-ci.yml on branch
You would generally create your .gitlab-ci.yml in the main/master branch.
Which means that .gitlab-ci.yml would not be impacted by merges between Test and Dev. Which is what you need.
Related
i trying gitlab pipeline. now i make some changes & code pushed in master branch
pipeline showing already update to date but i have changes in code
I try to pull in three phase but still same issue
.gitlab-ci.yml
before_script:
- echo "Before script"
building:
stage: build
script:
- git pull origin master
testing:
stage: test
script:
- git pull origin master
deploying:
stage: deploy
script:
- git pull origin master
If the gitlab-ci workflow starts by cloning your repository, no amount of git pull will change the fact you already have the full history, and, at the time of the workflow, this is "already up to date".
In other words, a git pull would not be needed in your gitlab-ci.yml file.
If your pipeline is running on the same repo that you changed, there is no need to use git pull. Although, if your pipeline triggers (on repo A) another pipeline on another repository (repo B), to access files in repo A, you have to pull repo A in repo B pipeline.
I have a gitlab ci which triggers a pipeline in another repository.
That pipeline does finish, but it does not cause the original pipeline to finish as well.
This worked up until a few days ago, we did not change anything in our gitlab ci's for both main repository and tests repository.
This is how the tests pipeline is triggered:
trigger_integration_test:
extends:
- .merge_request_rules
stage: test_on_dev
variables:
TEST_TYPE: ci
trigger:
project: <path to>/backend-inregration-tests-repository
strategy: depend
Gitlab version is GitLab Enterprise Edition 14.1.0-pre e230eeca384
Please advise on how I can resolve this?
The manual step at the end of the pipeline was preventing the main pipeline from finishing.
Once disabled it, everything returned back to normal.
I got two branches in my GitLab repo (uat and production). Two deploy jobs are meant to deploy a branch to a specific environment. There are two gitlab-ci.yml files, one in each branch (with the config for that branch) and production is my default branch.
The jobs should run only if files in dir/ changed and not for scheduled pipelines.
Problem: The deploy job for UAT is just working as expected: it runs if I push directly to the branch or if I accept a merge request. However, although there is no difference except the branch, the deploy job for production is not triggered on any event.
Question: Do you know if I misunderstood something and what would fix this?
Thanks!
gitlab-ci.yml in production
deploy_to_production:
only:
refs:
- production
changes:
- dir/*
except:
- schedules
script:
# upload to prod
gitlab-ci.yml in uat
deploy_to_uat:
only:
refs:
- uat
changes:
- dir/*
except:
- schedules
script:
# upload to uat
Do you have those empty lines before script: in your file?
This will define script under default, because it is not tied to a job.
default:
script:
# upload to uat
The reason that it is only running uat is that on the second reference the first one gets overwritten. You can check this on gitlab on your project page under CI/CD/Editor.
And here you can view the final yaml after merging:
Need to trigger CI build job when a PR is merged to master (only when change is inside ./rel/* path) but not have CI build triggered when the Pull Request (PR) is created. So I have the trigger config as below.
trigger:
branches:
include:
- master
paths:
include:
- ./rel/*
pr: none # will disable PR builds (but not CI builds)
But it fails to trigger CI build when pr: none is added. If pr: none is removed, The Job is getting triggered for both PR and a merge to master. I would only need the job/CI build to run on a merge to master.
The paths filter in the YAML is looking at paths in your repository file structure, not the branch path. To have it only trigger on rel branch, replace the master under the include branches with ./rel/* (or the correct value).
We have a more defined pipeline that runs unit tests on PR and then only packages for release on merge into the master branch. We do this by having our trigger set to the master branch and using conditions for each stage in the multi-stage pipeline. Check those out as well.
Solved! This works now.
trigger:
branches:
include:
- master
paths:
include:
- ./rel/*
pr: none # will disable PR builds (but not CI builds)
Also you can configure / override using the classic azure devops UI from Triggers.
Ref : https://learn.microsoft.com/en-us/azure/devops/pipelines/repos/azure-repos-git?view=azure-devops&tabs=classic#ci-triggers
I am currently having my project in GitLab and Heroku. What I wanna do is as soon as I ask for merge request with my feature branch (let's call it crud-on-spaghetti), I want to automatically run the tests on this branch (npm test basically, using Mocha/Chai), and after they succeed, merge this crud-on-spaghetti with master, commit it and push it to origin/master (which is remote on GitLab) and after git push heroku master (basically, push it to the master branch in Heroku, where my app is stored). I have read several articles on GitLab CI and I think this is more suitable for me (rather than Heroku CI, because I do not have DEV and PROD instances).
So, as of now, I do this manually. And this is my .gitlab-ci.yml file now (which is not committed/pushed yet):
stages:
- test
- deploy
test_for_illegal_bugs:
stage: test
script:
- npm test
deploy_to_dev:
stage: deploy
only:
- origin master
script:
- git commit
- git push origin master
- git pull heroku master --rebase
- git push heroku master
Hence, my questions is: What do I exactly need to write in .gitlab-ci.yml in order to automate all these "manipulations" (above)?
PS. And another (theoretical) follow-up question: how is GitLab-CI Runner triggered? For instance, if I want it to trigger upon merge request with master, do I do that using only: ... in .gitlab-ci.yml?
Restrict stages to Merge Requests:
To have your test stage only being executed when a Merge Request (MR) is opened, use
only:
- merge_requests
According to the Gitlab docs, you can further restrict this to only being executed for MRs with a certain target branch, e.g. only MRs for master
only:
- merge_requests
except:
variables:
- $CI_MERGE_REQUEST_TARGET_BRANCH_NAME != "master"
This adds an exception for all target branches that are not master.
Or use rules: for that:
rules:
- if: '$CI_PIPELINE_SOURCE == "merge_request_event" && $CI_MERGE_REQUEST_TARGET_BRANCH_NAME == "master"'
Restrict stages to Branches:
As already mentioned by #marcolz, this is achieved by
only:
- master
to only execute the stage for pushes to the master branch.
Try
only:
- master
origin is just a name for a remote. master is the name of the branch.
The runner is triggered by GitLab-CI the moment that a commit is pushed to the repository, so alas not upon merge request.
You can use a trigger to trigger a pipeline and then call that trigger from a merge request event in integrations.