How can I have a gitlab CI/CD job modify files of a different repo?
Consider the scenario where we have 2 Gitlab projects (repo1 and repo2). Repo2 uses releases of repo1 by referencing explicitly the version of repo1 it is using.
Now let's assume I am updating repo1 (resulting in a new version/release/build-something). Naturally I now want to update repo2 such that it is aware of the new version of repo1. But I want to do it automatically with a job being triggered on the repo1 ci/cd pipeline.
How can a job in a ci/cd pipeline of a repo change files for another repo?
If it helps, all considered repos are located in the same Gitlab group and share the same permissions
I have 4 target env Dev,QA,UAT and PROD
Each envs has 3 Azure VM , Web , API and Database
Should I Create
4 Deployment Groups Dev, QA, UAT and PROD and Add 3 targets in each of these 4 deployement groups and Tag those targets as Web, API and Database ?
Or Create 3 Deployment Groups Web , API and Database and add 4 targets in each group and tag is as Dev,QA,UAT and PROD ?
Or create 4 Environments (Dev,QA,UAT and PROD ) and add 3 resources in every env.
Note :
Not to mention , every env will have different connection-strings
If I already added one VM as a target in deployment group , I can not add it as a resource in environment
I want to use same release pipeline to deploy to Dev --> QA --> UAT --> PROD in stages with approval. Basically build once and deploy to multiple envs.
You cannot use environments with the classic release pipelines. So option 3 is out. However the described option would be valid if you used YAML pipelines to deploy your application.
Out of options 1 and 2, You should the first one because it has less room for errors and the production environment is better protected. You could also use 12 groups (one for each combination), but the additional effort is probably not worth it.
This would also follow the Microsoft recommendation.
Deployment groups represent the physical environments; for example, "Dev", "Test", or "Production" environment.
[...]
Enable you to use machine tags to limit deployment to specific sets of target servers.
I created a group "mygroup"
Created a repository "myrepository"
Add patch .gitlab-ci.yml#mygroup/myrepository as documented - https://docs.gitlab.com/ee/ci/pipelines/settings.html#custom-ci-configuration-path
but gitlab ci does not see this file from another repository.
Maybe we should do something else?
I worked with the same problem.
You should change mygroup and myrepository visibility to internal or public.
change group visibility
change repository visibility
I'm trying to set up different build jobs in Jenkins for different branches of a Gitlab repository. I'm using Gitlab web hook to trigger the build.
Here are the steps I followed to setup a web hook for Jenkins CI in Gitlab
Go to the project
Settings --> Integrations
Under 'Project Services', I've selected 'Jenkins CI'
Now I've checked the 'Active' checkbox
Jenkins url : <jenkins url>
Project Name : <jobname_on_jenkins>
and provided credentials.
In Jenkins, I've selected the under 'Build triggers', I've selected
"Build when a change is pushed to GitLab" and provided the branch filters.
Now, In Jenkins, I've created another job with branch filter as different branch name.
Now my question is, How do i setup a web hook in Gitlab to trigger a different Jenkins job when there is a change in a specific branch. I tried providing comma separated job names for the field 'Project Name' in Gitlab web hook for Jenkins CI but it's not allowing comma separated values there.
Other details:
Gitlab version : GitLab Enterprise Edition 10.8.7-ee 075705a
Jenkins version: 2.138.3
Plugins installed on Jenkins : Gitlab, Gitlab webhook
Just use two webhook - in the field branch name specify the name of the branch
When I try to select team member for a git repository in gitlab there I see no chance to assign a whole group. Is this a missing function? Or is it possible anyway?
I am using Gitlab 6.0