I'm trying to set a cross-repo branch policy to require approvals from admins anytime an azure-pipelines.yml file is touched. Seems easy:
Go to project settings -> repositories
Add a branch policy for "*" (all branches)
Add an automatically included reviewer: 1 required from "Build Administrators"; pull request affecting these folders: /azure-pipelines.yml. (I've tried various versions of this path too, e.g. with out slashes, with wildcards, explicitly excluding everything else, etc)
Save
The problem is it doesn't work. When I go and edit a file that is not azure-pipelines.yml file (e.g. readme.md), in a repo that has no other policies on it, I get stopped and it says I must submit a pull request. I would expect this commit to go through without a PR, since the policy does not include it. If I disable that automatically included reviewers policy, the commit goes through without a hitch.
I'm fully prepared to accept I'm using this incorrectly, but per the documentation, this seems like a bug. Anybody have any ideas? I've been trying various iterations of this for days.
Based on my test, I could reproduce this situation.
When you set a path filter for ·automatically included reviewers·, this path filter only affects the reviewer's branch strategy.
This is a scene：
When you make some changes in *.yml file and create a pull request, the required reviewer will be automatically added. In other cases, this reviewer will not be added automatically.
This is the function of this path filter.
For Cross Repository branch policy：
If you set the branch policy for *(All Branches), this means that all branches cannot be directly pushed, they all needs to creat a pull request.
This will affect all repos.
When the branch policy exists, you need to pass a pull request to push changes. There is no path filter at the branch policy level temporarily. Therefore, the branch policy cannot be made to skip the files in the branch.
But this requirement is valuable, this is a suggestion ticket with similar functions, you can vote and add your ideas in it.
Related
I have the following configuration on my branch on azure devops:
Sometimes I need to change some binary files (not readable) on my repos and it takes time from my team to just approve the pull request.
I want to exclude this obligation when I'm changing just these binary files. These files are related to my app's documentation and all of them have the same file extension.
No there isn't, you could move those files into a new repo and not apply branch policies to that new repo. Then turn that repo into a package(NuGet, NPM, Maven, etc). So you can easily reference those binaries.
Is there a way to exclude specific files from code review obligation on Azure Devops?
Indeed, there is no way to simply exclude source controlled files from Code Review.
To resolve this issue, the best way is create a new branch based on your current branch. And then change these binary files in the newly create branch.
When you complete your modification or you need code review, you can create a PR to merge the newly created branch into your current branch, and the Branch policies of the current branch will work.
This will avoid frequent code reviews during the time you modify the binary files, and also protect your current branch before you have completely completed your modifications and verification.
Hope this helps.
I have a project on AppVeyor that I want to build in two (or three) different scenarios:
Anytime it's on the master branch no matter which files changed, but not a pull request
If it is a pull request on the master branch when certain files have changed
(Maybe if it's on a different branch when certain files have changed)
Is there a way to configure appveyor.yml to do this? I'm aware of how to use APPVEYOR_PULL_REQUEST_NUMBER in one-liners, but I want to be able to apply it to the entire appveyor.yml, and combine it with the only_commits: options.
You can create 2 projects on AppVeyor connected to the same GitHub repo:
For the first project got to GitHub repo settings, find Webhook connected to this project and uncheck pull request
For the second project set only_commits for those certain files according to commit filtering doc
Optionally, for the first project set skip_commits for the same files according the same commit filtering doc, to eliminate duplicate builds.
Scenario:
Job 1 should be triggered on every new commit to github repository.
Job 2 should be triggered only when adding a tag to that same github repository.
If I configure the Github Plugin to use webhooks, it seems that if I try to set 'Branches to build' to anything permissive (**/* or refs/heads/*), it will build any push to github - which includes adding and removing tags.
Additionally, I can't seem to find a way to ignore all commits, and ONLY build tags.
I'm using Jenkins 2.32.3, Git Plugin 3.1.0, and Github Plugin 1.26.1
Im going to start off by saying that this might vary depending on jenkins and plugin versions.
But in the normal git plugin, when you go to the job config you can select Additional Build Behavior. Under add you can select to ignore commits with certain messages (i.e. comments) or to ignore commits by certain commiters (i.e. the build user)
I want to accomplish following via teamcity in my CI box.
Master branch commit : Build and Release
Beta branch commit: Build and Release to Crashlytics
All other commits to any other branch: Build
(side note since most of our development branches may or may not contain a prefix, it makes it difficult to use "feature-*" branch naming)
Following this question Select Git branch for TeamCity Build
I have created a Configuration Parameters in my project settings
and then
my VCS root settings
Then I created a build template
When I created builds I made sure branch name is correct
I have also tried to edit Triggers
How ever this is not working because when I push a commit to Beta branch
I think because of ref/heads/* default build is running all the branches
and Beta and Master displays "Pending"
How can I correct this?
I solved the problem by talking to other developers and making sure that all development branches uses a prefix, in this case XAAI-
then in my VCS root settings
for triggers in each build configuration I make sure it only is triggered when that branch is checked in.
for example for QA (Betabuild)
this is the tricky part , for Development branches I had to give an empty parameter, I dont know why (maybe because something needs to check default branch which is supposed to be ref/heads/) but whatever the reason it is working.*
and then finally whole thing looks like this
That pending thing is still annoying but , I think at least it is working as I envisioned now.
If you want your builds to only trigger automatically when the default branch is pushed to, you can add a branch filter to the trigger like so +:<default>.
This is dependent on the assumption that you have setup the %BranchName% parameter in each build configuration correctly. IE, for your Default build, make the %BranchName% parameter = master.
As a side note, you will still see all pending changes for each branch, but the trigger will only run when you push to your default build if you add the branch filter. If you want to get rid of the pending changes for each branch, you'll need to setup your vcs root specfic for each configuration to filter out the branches all together.
I have already used some VCS like CVS, SVN and Git. One feature that I am missing cannot be found anywhere.
There are files which I would like to have in the repository but every user should have its own. So when you checkout you get a default of that file and that commit your changes only for yourself.
Why do I want this? There are some files like configuration where I would like to have a default version in the repository (e.g. for building releases or a starting base for new team members) but the changes to that file are only relevant to a certain developer (or working copy) because it will contain paths only valid for that developer/working copy.
Currently when I do not add this files:
- I miss them when creating a new working copy or exporting for a release build
- Have no history which changes I might have done for myself for experimenting
Currently when I add this files to the repository:
- I might never commit them so I have a default in the repository but my file is always flagged "changed". In SVN I can add it to the "ignore-on-commit" changelist to improve a bit.
- I might loose my very own changes of a difficult configuration file (data crash, laptop theft, etc.)
Is there a VCS capable of this? Do SNV or git support something regarding this I might have overseen?
If I understood and decomposed your task correctly
"Have a set of default templates of something, which are starting point of per-user customization and these customized versions must be stored separately and be accessible only by responsible person"
you can use this workflow (draft, subject of modifications and corrections), Subversion based for simplicity and transparent management (strong point of any CVCS really)
Subversion repository
Each user of repo have own predefined path inside repository-tree (with common path-pattern for manageability and easy automation of processes)
One special admin-only managed path also exist, not accessible by ordinary users
Our tree may seems like this (where Repository dir is a root of repository)
z:\>dir /s /B
z:\Repository
z:\Repository\Users
z:\Repository\Template
z:\Repository\Users\Alpha
z:\Repository\Users\Bravo
For every user-path we use Path-based Authentication, which provides access for every and each user only to own subtree in repository,
Template contains (as name assumes) templates stub for all user's documents
Adding new users to repo, obviously, becomes simple and easy automated task:
svn copy Template into new user's dir
add rw permissions for created location for user in authz-file
tell user URL of his personal tree in repo
I don't think the VCS is the problem here. It looks like if you have a file whose contents are dependent on the local environment, you should auto-generate it with a script. This way, you ignore the generated file, but version the script and each developer still gets a perfectly valid copy of the config files at run time. This is the same approach that is used, for example, with user specific IDE settings: .suo files on Visual Studio for example.
Update:
If you specifically need a set of defaults, then the solution is this:
Add the defaults to the repository.
Each dev works in their own branch. This way, they can version the
changes to the config files.
When re-basing onto master and/or merging, the devs simply never
merge their customized configs.
You can always set up a hook to check if the default config has been modified, and if so, maybe email the dev. You simply view such a commit the same as you would view a commit that does not compile.
Devs are smart. Sure, they make mistakes. But never under-estimate the power of some simple communication.
Of course, when the default configs do get overwritten with the customized ones of Dev X, then you use the powers of git to fix that commit immediately.