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.
Related
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.
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
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.
I have a GitHub status check generated by TeamCity, and I'm trying to delete it (not just disable it).
I've tried (line breaks added for readability):
curl -u <myusername>:<mytoken>
-X DELETE
https://:github_instance/api/v3/repos/:user/:repo/statuses/:hash
I got the url from:
curl -u <myusername>:<mytoken>
https://:github_instance/api/v3/repos/:user/:repo/statuses/:branch_name
Am I missing something?
Like #VonC I couldn't find a deletion option. However, you can disable any existing checks so that they no longer run on your PRs.
Settings
Branches
Branch protection rules
Edit (next to your desired branch, e.g. 'master')
Rule settings
Require status checks to pass before merging
Require branches to be up to date before merging
< Uncheck any statuses you want to disable! >
I see the GitHub API V3 Repository Statuses (for github.com or for a private GitHub enterprise instance) includes:
Create a status
List statuses for a specific ref
Get the combined status for a specific ref
There is no deletion as far as I can see.
We use Jalopy to reformat the code. On jenkins/svn, we checked out, formatted and commited again. Now on bamboo/stash, we want to do the same.
We set up this restriction for the master branch:
Prevent changes without a pull request (Everyone)
(AFAIK, it is not possible, to exclude certain users from this rule, is it?)
Now, as expected, when we try to push the formatted sources, we get this error:
remote: Branch refs/heads/master can only be modified through pull requests.
remote: Check your branch permissions configuration with the project administrator.
remote: ----------------------------------------------------
remote:
To ssh://git#mystash.com/proj/proj1.git
! [remote rejected] master -> master (pre-receive hook declined)
error: failed to push some refs to 'ssh://git#mystash.com/proj/proj1.git'
Any suggestions on how we can keep the enforcement for pull requests, while still being able to push directly to master from a Bamboo script? Or any better approach?
That is currently correct ... kind of. The Stash UI doesn't provide a way to set this (or see if you have) at the moment. However, the REST API will actually let you set branch permissions and specify users who are exempt. For details, see this comment on the feature suggestion to add full support.