Is there a way to exclude specific files from code review obligation on Azure Devops? - azure-devops

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.

Related

Azure Devops Cross Repository branch policy path filter not working

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.

What does it mean to check-in Code

I am new to the DevOps world and I am reading about Continuous Integration, What does it mean to check-in your source code. Does this mean pushing it to the branch after you write the code?
Checking-in code means to upload code to main branch repository so that its administrator can review the code and finally update the project version. Additionally, checking-out code is the opposite which means to download a copy of code from the repository.
For example, on GitHub, cloning means checking-out code and pull request means checking-in code.

Only run AppVeyor build on certain conditions

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.

Exclude a config file from the merge process

Is there a way to exclude a specified file from the merge process? when merging from our production branch to the test branch for the testers to use, we want to exclude a config file which contains the SQL connection string. Preventing the need to edit it post merge. I did see a comment about using the cloak option but i can only see this available for folders not files.
Tim
There are a few different ways you can do this. If you don't plan on changing your config file in the future and you just don't want its current contents to make it to the parent branch, you could simply do a "tf merge /discard" on the file and check that in. That basically says, never merge the changes that have happened to this file to the target branch. However, if the file changes again, it will be a candidate for a merge.
So, if you plan on continuing to change the config file in question, then you have two options. The first is to always cloak this file in the target branch workspace that you are performing the merge in. Yes, it is possible to cloak files, it is just the picker in the dialog doesn't make this easy. If you navigate all of the way down to the containing folder, select that and then manually enter the file name at the end of the folder string, the cloak will work on the file. This approach has the downside that you have to remember to always cloak this file in the workspace that you are performing the merge in and if someone forgets to do that, the file will be merged up.
The third, and likely best, solution to this problem is to use the tfpt.exe power tool with the branches command to cloak the config file from the parent's branch mappings. You can download the latest 2010 power tools here. You will want to run "tfpt branches /properties /collection:" and then select the "mappings" channel. In there you will probably just see a single mapping for the root of the branch. You will want to create a cloak mapping for the file you do not want to be merged and then click OK. On all subsequent merges to that branch (note, from any other branch) the file in question will not be merged.
Not a very nice solution, but you could remove the checkin security on that file so you are unable to checkin the file after a merge.

TFS - Cannot see Target branch when doing file Merge

We faced an issue with file Merge at TFS2010. Until now, we merged files from one branch to another without problems (right click at file -> Merge -> Choose Target branch and Merge files). Initially, we added new file at Develop branch, after that added same file at Main branch. After some period we had changes in code at Develop branch and when tried to do Merge with Main branch, cannot see Target (Main) branch. I have two questions regarding to this situation:
Is this good way for 'uploading' new files at TFS. Separately add files at both branches or there is some better practice where we could add new file to Develop branch and after that make copy of that file at Main?
What can be reason for 'hiding' Target branch during the Merge operation?
When tried to solve this problem, I found some articles that can be useful to someone else, but didn't solve problem in my case:
TFS not showing Dev branch in target locations for merging
How to merge new files into another branch in TFS?
http://revweblog.wordpress.com/2010/03/31/missing-target-branch-while-trying-to-merge-in-tfs-baseless-merge/
TnX in advance!
Nemanja
I think the case you should look closer is this, it's a case you have already mentioned.
To your first question:
No, your method of committing new files multiple times is not optimum. Adding a new file into source control (any source control) more than once, doesn't make sense.
To your second question:
The reason behind this behavior was best explained by AakashM in the post above: "In TFS the unit of change is the changeset, and it is changesets (not files) that are checked-in and merged. In the version (changeset number) that the target branch is at, this file simply does not exist, so there is nothing to merge to."
The proper way to operate is to add new files in your 'Development' branch and then merge into your 'Main' branch.
This will not be possible if you right-click on the newly added file & choose "Merge.." (no target-branch will be presented). This will be presented if you do this in the folder containing you new file(s).
I had this issue, when for the Main Branch i did not had the latest code. I Took latest code in Main Branch and then tried Merge to development branch and it worked.