Add branch policy in AzureGit with directory pattern - azure-devops

I am trying to add a branch policy (automatically include reviewers) for all branches that will be created under the following pattern automatically. Is there any way to achieve this?
Pattern: release/{DIR name}/int
eg:
release/abc/int ,
release/bcd/int ,
release/efg/int
For the branch named with 'int' should applied with the above mentioned policy.

Related

How do you restrict which branches can be pulled into a target branch

I'm trying to set up policies on my Azure DevOps Branches.
I'm able to state that a branch must build and pass our unit tests before allowing a merge but is there a way to restrict which branch is allowed to merge into it.
I have two branches that this would impact.
I have my 'master' branch that I would like to restrict to only accept pull requests from a branch called 'UAT'.
I have a branch called 'UAT' that I would like to restrict to only accept pull requests coming from a branch called 'Dev'.
The closest workaround I could think of is to have a very simple pipeline that would run on pull requests and check System.PullRequest.SourceBranch and System.PullRequest.TargetBranch. If the values don't match your policy, then fail the pipeline, which in turn will block the PR.
Based on the answer by qbik i created this short yaml code. Replace the source and target as needed for your use case. The code below is only for testing in my pipeline, to create the desired failure.
- powershell: >
if ("$(System.PullRequest.SourceBranch)" -ne "refs/heads/acc" -And "$(System.PullRequest.TargetBranch)" -eq "refs/heads/test")
{
Write-Error "
=========================================================================================================
Branch check failed.
Illegal Pull Request from $(System.PullRequest.SourceBranch) into $(System.PullRequest.TargetBranch).
========================================================================================================="
}
displayName: Branch Check

Protect branch in Github results in "Rule is invalid"

I'm trying to create a simple rule to protect the main branch of a repository but it results in Rule is invalid. I am the creator of the repo. Using GitHub Enterprise Server 2.22.6.
What am I missing?
Steps:
Settings
Branches
New Rule
Name the rule Enter branch name to protect (answer)
Select Require pull request review before merging
Create
Error: Rule is invalid
Try entering a regular expression or the name of the branch you'd like to protect (e.g. main instead of Protect Master) into the Branch name pattern textbox.
See the docs here for more information.
For anyone still struggling with this. Make sure there is no space in your rule name.
ie:
"Protect Main" -> error
"ProtectMain" -> fine.
Name the rule as the branch name, so that it is applied to the specific branch you intend.

Is there a way in Terraform Enterprise to read the payload from VCS?

I have configured a webhook between github and terraform enterprise correctly, so each time I push a commit, the terraform module gets executed. Why I want to achieve is to use part of the branch name where the push was made and pass it as a variable in the terraform module.
I have read that the value of a variable can be a HCL code, but I am unable to find the correct object to access the payload (or at least, the branch name), so at this moment I think it is not possible to get that value directly from the workspace configuration.
if you get a workaround for this, it may also work from me.
At this point the only idea I get is to call the terraform we hook using an API Call
Thanks in advance
Ok, after several try and error I found out that it is not possible to get any information in the terraform module if you are using the VCS mode. So, in order to be able to get the branch, I got these options:
Use several workspaces
You can configure a workspace for each branch, so you may create a variable a select that branch in each workspace. The problem is you will be repeating yourself with this option
Use Terraform CLI and a GitHub action
I used these fine tutorial from Hashicorp for creating a Github action that uses Terraform Cloud. It gets you done the 99% of the job. For passing a varible you must be aware that there are two methods, using a file or using an enviromental variable (check that information on the Hashicorp site here). So using a:
terraform apply -var="branch=value"
won't work. In my case I used the tfvars approach, so in my Github Action I put this snippet:
- name: Setup Terraform variables
id: vars
run: |-
cat > terraform.auto.tfvars <<EOF
branch = "${GITHUB_REF#refs/*/}"
EOF
I defined a variable within terraform called branch, I was able to get and work with this value

GitHub Actions: Are there security concerns using an external action in a workflow job?

I have a workflow that FTPs files by using an external action from someuser:
- name: ftp deploy
uses: someuser/ftp-action#master
with:
config: ${{ secrets.FTP_CONFIG }}
Is this a security concern? For example could someuser change ftp-action#master to access my secrets.FTP_CONFIG? Should I copy/paste their action into my workflow instead?
If you use ftp-action#master then every time your workflow runs it will fetch the master branch of the action and build it. So yes, I believe it would be possible for the owner to change the code to capture secrets and send them to an external server under their control.
What you can do to avoid this is use a specific version of the action and review their code. You can use a commit hash to refer to the exact version you want, such as ftp-action#efa82c9e876708f2fedf821563680e2058330de3. You could use a tag if it has release tags. e.g. ftp-action#v1.0.0
Although, this is maybe not as secure because tags can be changed.
Alternatively, and probably the most secure, is to fork the action repository and reference your own copy of it. my-fork/ftp-action#master.
The GitHub help page does mention:
Anyone with write access to a repository can read and use secrets.
If someuser does not have write access to the repository, there should be no security issue.
As commented below, you should specify the exact commit of the workflow you are using, in order to make sure it does not change its behavior without your knowledge.

In a multi-repo deploy, how can I can I keep the pipelines co-located with their source code

I have a Deploy to IBM Cloud button that deploys 3 git repos and works great except I have a maintenance problem. If I make an edit in one of the repos which impacts how it is built, I have to change the pipeline.yml which exists in another repo, namely in the same repo as my .bluemix\toolchain.yml. I would prefer to have my pipeline.yml files self-contained in the repo they actually pertain to. My toolchain.yml has 3 entries like:
services:
dashboard-build:
service_id: pipeline
parameters:
services:
- dashboard-repo
name: 'dashboard-{{toolchain.name}}'
configuration:
content:
$ref: dashboard.pipeline.yml
$refType: text
I tried an absolute path like:
ref: https://raw.githubusercontent.com/org/repo/master/.bluemix/dashboard.pipeline.yml but it errored out with
repository contains an invalid template. File not found
Can I change the pipeline's location to be in its own repository or does it have to be co-located with the toolchain.yml?
Yes, as you've guessed any files referenced with $ref or $text must be co-located in either the same repo or zip file. We might offer support for referencing and extending another template in the future but there is nothing concrete there yet.
--
Also...
$text should be used in preference to $ref and $refType here.
The pipeline's "content" element expects raw text and historically that is why we added $refType: text. However, $ref as specified in JSON Reference explicitly ignores siblings so although we have support for $refType currently it would be better to just use $text going forward.
content:
$text: dashboard.pipeline.yml