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.
Related
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.
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.
To set expectations, I'm new to build tooling. We're currently using a hosted agent but we're open to other options.
We've got a local application that kicks off a build using the VSTS API. The hosted build tasks involve the Get sources step from a GitHub repo to the local file system in VSO. The next step we need to copy over a large number of files (upwards of about 10000 files), building the solution, and running the tests.
The problem is that the cloned GitHub repo is in the file system in Visual Studio Online, and my 10000 input files are on a local machine. That seems like a bit much, especially since we plan on doing CI and may have many builds being kicked off per day.
What is the best way to move the input files into the cloned repo so that we can build it? Should we be using a hosted agent for this? Or is it best to do this on our local system? I've looked in the VSO docs but haven't found an answer there. I'm not sure if I asking the right questions here.
There are some ways to handle the situation, you can follow the way which is closest to your situations.
Option 1. Add the large files to the github repo
If the local files are only related to the code of the github repo, you should add the files into the same repo so that all the required files will be cloned in Get Sources step, then you can build directly without copy files step.
Option 2. Manage the large files in another git repo, and then add the git repo as submodule for the github repo
If the local large files are also used for other code, you can manage the large files in a separate repo, and treat it as submodule for github repo by git submodule add <URL for the separate repo>. And in your VSTS build definition, select Checkout submodules in Get sources step. Then the large files can be used directly when you build the github code.
Option 3. Use private agent on your local machine
If you don’t want add the large files in the github repo or a separate git repo for some reasons, you can use a private agent instead. But the build run time may not improve obviously, because the changed run time is only the different between copying local files to server and copying local files to the same local machine.
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.