Gitlab pipeline checkout access - gitlab

I'm trying pipelines in git lab community edition.
For what I can understand, from gitlab, the code and pipelines live in the same git repository.
In my scenario the pipelines are responsibility of devops team and code from develop team.
How, in git lab, is possible to prevent developers of changing the pipeline?
I understand it's possible to add devops team as maintainer to review pull requests, but this will create a dependency of devops teams in every change.
thanks

GitLab is not really designed for the scenario you describe. The general idea is that developers look after the CI configuration themselves.
You could try using the includes feature to store the bulk of the CI configuration in a separate repository.
In the application repository you would have a .gitlab-ci.yml file that pulls the CI configuration in from another repository using include-project:
include:
- project: 'my-group/my-ciproject'
ref: master
file: '/ci/.gitlab-ci-myappproject.yml'
Then in the my-group/my-ciproject repository you would have a file .gitlab-ci-myappproject.yml that contains the GitLab CI jobs configuration.
build:
script:
- dobuild
Only the DevOps team would have access to the my-group/my-ciproject repository so developers can't edit the CI config (although could mess with the .gitlab-ci.yml` file in the app repository).
Alternatively you could protect the master branch and have all changes approved before merging to master. Then developers would not be able to make changes to the CI without an approval.

Related

Synapse pipeline import resource from git

I have a situation here where I import resources from my Azure DevOps Git repository DEV to TEST, I want DEV code to be independent of TEST and not commit my changes back to the repository.
After I import the repository to TEST I made changes to the SQL database connection string in the copy activity source and sink in TEST and had to commit the changes for the debug to run and the triggers I have setup for the pipelines don't run in TEST as per the schedule and fail in DEV because of the changes I did in TEST.
When move the pipelines and underlying objects to different environments, How do I make all the environments independent once I import repository? Is there a way to copy from the repository to the Synapse live mode to accomplish this?
OR How would I automate deployment of Synapse pipelines? Is it using ARM or Bicep Template?
You'll want to follow Microsoft's guide on CI/CD with Synapse. This is a great walkthrough video for the process.
The flow is:
Work in your development environment and commit to your collaboration branch.
A pipeline triggers off of your workspace_publish branch, releasing your code to your next environment (preferably with an approval gate)
Continue releasing the same code to higher environments, again with approval gates.
For Azure DevOps, you can use variable groups to parameterize your pipeline. Also make sure to read through the custom parameters section on that link to parameterize parts of the template that are not parameterized by default.

Azure CI pipeline trigger not working after git instance migration

I have few CI and CD pipelines in azure devOps project in which CI pipelines connect to github enterprise repository to fetch the code.
CI pipelines were invoked by the trigger whenever there is a change in main branch of repository.
This was working fine until our git repository instance was changed. All our git repositories are migrated to the new instance.
I have updated the service connection, to point to the new git instance and manually invoked CI pipelines and tested. It worked fine.
But the issue is now with automatic triggering of CI pipelines. It is not working now.
I tried remove and add git service connections and repository details inside CI pipeline and enabled trigger, but still it is not getting automatically invoked whenever there is a change in repository.
What could be the reason for this ? I already removed and added the git repository details in CI pipeline, still that does not work. Is there anything I missed out? Any leads appreciated!
You can check the "Override the YAML trigger from here" setting for the types of trigger (Continuous integration or Pull request validation) available for your repo." in the Triggers UI.
If it does not work, please create a new pipeline to check if it works.
For more information, you could refer to: troubleshooting failing triggers
Finally figured out the issue and fixed. It was error with web hook in the repository.
Updated the webhook and it is working fine now.

How to Trigger a build pipeline depends on create PR request source branch in Azure DevOps

I have a Develop branch and Master. My task is to trigger the build pipeline when I create a Pull Request from Develop to Master before merge, depends on Develop branch. The trigger should be from source branch. Can we add tags to trigger the build pipeline based on source branch. I am using classic pipelines and new to ADO. how can I achieve this. Please someone help me to achieve this in detail.
To get a pipeline to trigger when a PR is opened but before it is merged you would need to add a branch policy on master branch to have a build validation step. This will trigger the pipeline to run whenever a PR is opened to master
Build Validation
Unfortunately, PR trigger behaviour varies, depending on which SCM you're using: Azure Repos Git, GitHub, or Bitbucket Cloud. With BB Cloud, the PR build will be triggered when the PR is opened or updated, but not when it is merged. The filter input can be used to specify branches for PR trigger.
Details for each SCM system can be found by clicking on the links on the "Triggers in Azure Pipelines" documentation.
The way how to set that up does depend on your source-code version control software you are using. For GitHub you need to install the "Azure Pipeline" GitHub App.
Then configure a pipeline in AzureDev Ops and enable "Continous integration" in "Triggers" section.
P.S.: To avoid that the compile check of a PR will result in published artefacts you can either have to different pipelines or - that's what I try to achieve - one pipeline where the artefacts are just being generated when the PR is merged.

Manage API Mangement from central GIT Repo in Azure Devops?

We have multiple teams working on the same Api Management instance, and the current git-based configuration that API Management provides, does not really facilitate a good process for us (with support for code reviews, pull requests, deploys etc.).
Can we use a GIT repository in Azure DevOps to control the configuration instead of having to use the repository provided directly by API Management?
Our primary use cases are:
Merge/sync changes from API Management into our central repository
Performing changes in a DevOps repo in separate branches, merge the changes to the main branch via pull requests and sync'ing the changes to API Management
We can clone the configuration repository and push changes back- using our familiar Git commands.
You can try to run the following command in cmd task of azure devops pipeline.
git clone https://username:password#{name}.scm.azure-api.net/
git add .
git commit -m "abc"
git push
Here are the document and similar case you can refer to.

Manual deployment from source control instead of automatic deployment?

I have two sites set up in Azure, a staging site and a production site.
Both sites are connected to the master branch of my git repository.
The stage site gets automatically updated when I commit a change to the master branch. What I'd like to do is have production set up so that it won't automatically be updated, but I can manually update it when I want to.
Basically so that changes will get pushed to stage, and when I'm ready for them to go to production, I can manually push them.
Is there a way to do that in Azure?
You have a couple of options:
Use a separate branch to deploy to production. For example a release branch. When you commit to the release branch, production will be deployed. This way you decide when will be deployed to production.
Another option, which is a bit more work. (especially if you have not done it before), but has it's advantages because of more control over the deployment:
Create a VSTS account in Azure. In the VSTS account create a project. Setup a build against your source to create artifacts which can be used in release management. Create a release which can deploy to Staging, and for example after a approval to production. (It's also possible to configure a swap here if you like, to release to producton)
For information about this:
https://www.visualstudio.com/en-us/docs/build/apps/aspnet/aspnet4-to-azure
https://www.visualstudio.com/en-us/docs/build/apps/cd/deploy-webdeploy-webapps

Resources