I am curious if it's possible to have the Assign function automatically set a pre-defined list of assignees when creating a Merge Request in GitLab.
I thought I might automate this function so I don't have to add assignees myself every time I make a Merge Reuqest.
Codeowners function provided by GitLab seems to not work in this regard... Is there any other way?
You can assign approval settings to merge requests by navigating to your project Settings > General > Merge Requests. You can create specific rules for a certain branch or for all branches:
Related
Various posts (including Github API - create branch?) give the API calls to make to create a new branch in a github repo, and can obviously be used in a script. I have a slightly different usecase though: I need to create a release branch (like release-1.2.3) when I already have a branch protection rule to cover release-*. The problem: without the branch protection rule, the linked method worked, while with it I get error:
422 Unprocessable Entity
The branch protection rule is fairly standard: requires a PR, requires a status check (I believe only applies to the PR?), "Restrict who can push to matching branches" and "Restrict pushes that create matching branches" are ticked and set to a group that contains all our main team, but includes the user who corresponds to the Jenkins job from where I am running this from.
My guess is that if I can use the new(ish) "bypass branch protections" and clear the "Do not allow bypassing the above settings" settings in the rule would work - can't actually try as yet because I don't have the rights to create the associated custom role but probably will. Alternatively creating the branch on a local repo and pushing it should work given the permissions (yet to try as more scripting but probably will). Question: has anybody got an easier way of doing this?
We are using Azure Devops to store our repo (Git) and run a pipeline.
The project type is .Net.
On recent PR that trigger pipeline, we noticed the pipeline failed because the developer removed a necessary file (PS script file).
Is there a way to prevent it -> somehow define that the pipeline will always "guard" some files in the main, and not let them be modified from other branches?
You can get really close to your goal by adding a branch policy called Automatic Code Reviewers based on specific files or directories. You can set the reviewer to a specific person or group of people, and any time a PR is modifying the "protected" file(s) the PR will not be able to be completed until one of those people approves the PR. If none of those people approve it the PR will not get completed. The nice thing about this is when you purposefully do wish to modify the file(s), you still can, but you just need to request that a certain group of people also approve the PR.
Tip: I recommend using groups for automatic code reviewers instead of specific people, even if the group has only one person in it. That way an admin can add/remove people from that group as needed, for example when certain people who normally approve the PRs are on out of office. It feels a little cleaner to adjust group membership temporarily, than to adjust the branch policies themselves on a regular basis.
I have a GiHub repository with GitHub actions based workflow (/.github/workflows/build.yml) to do CI builds.
I am from the DevOps team, my case, folks from development team are not allowed to change CI pipelines, they can change whatever they want on a feature branch except “/.github/workflows/build.yml”.
How to prevent a developer changing GitHib workflow to see his app changes passing through different type of integration build quality checks ?
Is there any better approach to achieve this other than options mentioned below ?
1] Through PR reviews
2] Script/automation to validate PR to see if dev did any changes to (/.github/workflows/build.yml
With code owners you can specify who is allowed to modify certain files like so:
# .github/CODEOWNERS
.github/workflows/build.yml #myorg/devops-team
Somewhat off-topic, but note that Toughtworks does not recommend to separate code and pipeline ownership:
[..] in general we find it painful and unhelpful.
I am looking to create Github repos with branch protection such that any merges to main branch requires certain checks to pass. We bootstrap Github repositories using code. The issue I am facing is to enable branch protection these checks need to exist beforehand. I have tried creating a webhook on push and added code to create checks and then add rule for branch protection but this way there is a small amount of time where there is no check and anyone can merge in this time. Can someone suggest what I can do to avoid this. Thanks!
I am using Build Pipeline: VSTS and Repo: VSTS
I am trying to create VSTS build pipelines for two branches Dev and UAT. I can achieve it by creating two different pipelines but since both has almost similar steps so I wanted to have only one pipeline and depending on condition I can omit some steps. But I am not able to figure out how to pass the variable value(branch which triggered the build) before queueing the build in VSTS.
Background: I tried to get both branch source, setted triggers on both branch and use Build.SourceBranchName variable but it is giving value the top level(Project) value instead of branch name. I have structure like below
Project
- Dev
- QA
The agenda is to trigger the build pipeline on checkin, sanity checks an publish the artifacts as per the environment(Dev,QA). I am not going for CD right now (will be handled manually because of some constraints).
The solution might sound very awkward but I am a newbie and I want to learn it.
I have checked some people have explained through API but any way to do through UI?
VSTS use API to set build parameters at queue time
Any help would be highly appreciated.

To add a variable that you can pass the value when you queue the build you need to go to variables tab, then add your variable and check the checkbox Settable at queue time.
Now when will queue a build you can change the default value.