I am using standard GitLab runner.
I need to determinate updates of master branch and updates of development branch. Beacause I want to copy master branch to production server and dev branch to test-server.
But I have only one .gitlab-ci.yml file which starting after 'git push'.
If I am register second runner. it is also controller by .gitlab-ci.yml
What to do?
In gitlab ci config file, we have the only option allowing to trigger a job only from a specified branch.
Doc at docs.gitlab.com/ce/ci/yaml/README.html#only-and-except
Related
good day. i try to ask same question on teamcity support forum but with no luck, so i try to find solution here
i have 4 (actual more, but other configuration not important for the situation):
'verify' - configuration that run test, check that all migration can be applied to database (run in docker) etc. this configuration triggered by gitlab (integration with teamcity feature)
'build' - configuration that build all application components and push docker images to hub
'deploy to test' - use corresponded artifacts from 'build' configuration and perform deploy images to test server
'deploy to staging' - same as 'deploy to test' but use staging server
'deploy to production' - same as 'deploy to production' but use production server
we have several stream in out repository with corresponded rules:
develop
feature/* - feature task that should be build then corresponded merge request to develop was initiated. merged to develop
release/* - release that should be deployed to staging server at each commit. merged to develop and master
hotfix/* - hotfix that should be deployed to staging server at each commit. merged into develop and master
master - stable branch, should be deployed to production on commit.
so, i create following VCS root:
default branch: refs/heads/develop
branch specification:
+:refs/heads/(*)
+:refs/heads/master
+:refs/heads/release/*
+:refs/heads/feature/*
+:refs/heads/hotfix/*
+:refs/(merge-requests/*)
after that i setup branch filters (for VCS Trigger) for each branch configuration:
verify - none
build:
+:refs/heads/release/*
+:refs/heads/hotfix/*
+:refs/heads/develop
+:refs/heads/master
deploy to staging:
+:refs/heads/master
+:refs/heads/release/*
+:refs/heads/hotfix/*
deploy to test:
+:refs/heads/develop
deploy to production:
+:refs/heads/master
so this is my setup, now my problems:
then gitlab trigger teamcity (on merge request) the verify configuration started. but i see following message (for example):
The build was triggered in the branch feature/VTS-610 which does not correspond to any branch monitored by the build VCS roots (the branch is either closed or excluded / not matched by any branch specification). Because of that default branch revisions were set to this build.
same message i can see if merge request initiated for hotfix branch (of course with another branch name, ie hotfix/VTS-654).
after hotfix branch merged (we create two merge-request: one to master and one to develop), i can see that deploy to staging was triggered, but deploy to test does not.
I had the same problem, the root cause in my case was the predefined build parameter teamcity.build.branch (see Build Branch Parameters)
The parameter was set in the build configuration of the failing build under "Parameters / Configuration Parameters". As I had no use for this parameter anymore, it was safe to just delete it. I was then able to run the build configuration with any branch that is accepted in the Branch Filter under Version Control Settings.
We have AutoDevops feature implemented with help of gitlab runner and managing the CD stage with ArgoCD. So the CI pipeline builds a docker image , pushes it to gitlab registry and CD stages use the pushed image to deploy the application with help of ArgoCD. On every commit, gitlab runner will trigger the pipeline. Is there are way in which we can use ArgoCD alone to handle this scenario so that the pipeline gets triggered automatically without having to configure runners?
To avoid having both gitlab runner and argocd running in your cluster, you would configure a gitlab webhook pointing to an ArgoCD Git Webhook Configuration.
Your ArgoCD application would then handle all the rest.
I have a gitlab repository which builds and runs all tests on a commit/merge. When creating a tag on the master branch I deploy the artifact on our nexus.
So here is what happens with my current ci configuration:
Merge a branch into master -> build/test
Tag merged master -> build/test, deploy
As you see the second build/test job is actually unnecessary in this case as no commit occurred between the merge and the tag.
Is there a way that I can configure a job conditional, if no change happened since the last pipeline execution?
There is a really good documentation on the GitLab pages: https://docs.gitlab.com/ce/ci/yaml/README.html#only-and-except-simplified
Your solution would be to add this in your build/test:
except:
- tags
Since GitLab 7.6, or thereabouts, there is a new option to use TeamCity directly from GitLab projects. In the setup there is this message:
The build configuration in Teamcity must use the build format number
%build.vcs.number% you will also want to configure monitoring of all
branches so merge requests build, that setting is in the vsc root
advanced settings.
I'm not sure how this works. Lets say I have a repository Foo.
I have setup a build on TeamCity to listen to Foo with branch specification: +:refs/pull/*/merge
I then fork Foo in gitlab as FooFork, make a change, then request a merge FooFork -> Foo.
But nothing happens to test this merge, which is what I was expecting GitLab to do. If I accept the merge than the build server jumps into action (immediately) and builds twice (master and /ref/master).
I've also set the build configuration to use exactly: %build.vcs.number% as the build number as prescribed, but gitlab doesn't seem to give me any information about the build result.
So I'm a bit confused really as to what exactly this GitLab -> TeamCity integration is supposed to do and whether I'm doing wrong.
I'm currently running GitLab 7.9 and TeamCity 8.1.4
Update:
Seems this use case was not supported prior to version 8 - https://github.com/gitlabhq/gitlabhq/issues/7240
I'm running GitLab 8.0.2 and TeamCity 9.1.1 and am able to run CI builds on branches and merge requests.
I trigger CI builds for specific branches by setting a VCS trigger together with the branch specification +:refs/heads/(xyz*) where xyz is the string for our ticket system prefix since all active branches need to be named after an entry in our issue tracker.
I trigger builds for merge requests via the branch specification +:refs/(merge-requests/*)
Everything works as as expected and lets us know the status of all feature / bug branches and merge requests automatically.
Thanks to Rob's comment linking to the GitLab 8 release notes entry on the merge request spec.
Same problem here. There might be another way, I'm evaluating right now. Since there's no direct way of getting the merged state from the target MR, you have to build it on your own:
IMO there's the following todos
1.) init a bare repo $ git init
2.) add your target repo $ git remote add origin git#your-repo:<origin.group>/<origin.repo>.git
3.) add the remote/feature/to-merge's $ git remote add target git#your-repo:<feature.group>/<feature.repo>.git
4.) checkout your feature branch $ git checkout -b <feature.branch> feature/<feature.branch>
5.) checkout your original branch $ git checkout -b <origin.branch> origin/<origin.branch>
6.) Rebase feature into your original branch $ git rebase <feature.branch>
As stated here [1], GitLab-CE can fire an event on creation of a merge-request,
so all you have to do is building some meta, that can evaluate the WebHooks.
[1] http://doc.gitlab.com/ce/web_hooks/web_hooks.html#merge-request-events
I am new to using bitbucket was trying just to set up simple build pipeline. Clicked on pipeline menu option and edited the example file and committed. This created a pipeline yaml file on my master branch. It ran and built ok - it did not build my develop branch.
Do i need a pipeline yaml file on each branch.
I can see from docs that i can put branch specific steps into the one file, if i edit the file that has been commited on master to include a section for the develop branch, will this run when i do a commit to the develop branch or will this only trigger on a commit to master branch.
Bitbucket will run the pipelines that has a corresponding definition for the branch that you have commited to. So, if you commit the pipelines configuration file to master, only default or master pipeline from this file will be executed. If you want to run a pipeline for develop branch, you need to commit this file to develop branch as well. Note, that the default pipeline is executed regardless of the branch name if there is no other pipeline defined for this particular branch. So, your comment is correct, you need to have the bitbucket-pipelines.yml in each branch.
Here is how Bitbucket will resolve the pipeline execution configuration^
If there is no bitbucket-pipelines.yml - no pipelines will run for the branch
If there is bitbucket-pipelines.yml and there is a default pipeline definition only, Bitbucket will execute the default pipeline.
pipelines:
default:
- step:
script:
- echo "Running the default pipeline"
If there is also a specific pipeline defined for a particular branch, lets say for develop, Bitbucket will execute this pipeline instead of the default
pipelines:
default:
- step:
script:
- echo "This will not be executed if the branch is develop"
develop:
- step:
script:
- echo "Running the develop pipeline"
Note, that if the branch name would be something else, lets say release, since there is no pipeline defined for release branch, the default pipeline will be executed.