Conditional build confirguration
My team deploys to a couple different places depending on where
we are with features in the development process, each place with a
unique branch and configuration (production, staging, etc). This is
pretty easy for us to setup with the deployment system, as we can
specify to only deploy when the update came from a particular
branch or is with a configuration:
configuration: - Release - Debug
deploy: - provider: Environment name: My Environment on: branch: dev configuration: Debug
However, even though we might only be using one configuration for a particular deployment, the build process happens for both. It would be nice if we could specify for a particular configuration to only build from a certain branch, much like we can do with deployments. Maybe something like the following:
configuration: - name: Release on: branch: master - name: Debug on: branch: dev
This would save some time, not having to build both configurations when only one is needed.
Comments are currently closed for this discussion. You can start a new one.
|?||Show this help|
|ESC||Blurs the current field|
|r||Focus the comment reply box|
|^ + ↩||Submit the comment|
You can use
Command ⌘ instead of
Control ^ on Mac
Support Staff 1 Posted by Feodor Fitsner on 03 Jun, 2014 06:46 PM
Why couldn't you have a specific appveyor.yml for every branch? For example, you can commit appveyor.yml in "dev" branch with
2 Posted by jffelsinger on 03 Jun, 2014 06:56 PM
One could do that, right off-hand I'm unsure how easy that would be to maintain though. If one was to make a pull request/merge from one branch to another wouldn't the differences in the two appveyor.yml's cause one to be overwritten? I don't know of a way to ignore a file only in relation to changes in other branches (I'm probably missing something obvious though).
Support Staff 3 Posted by Feodor Fitsner on 03 Jun, 2014 07:03 PM
OK, I see. This is what I expected to hear. Right, having build config in appveyor.yml has its pros and cons. The cons is that you can mess "master" config while merging dev branch into it.
Build matrix and deployment is one thing. Do you need branch-specific settings for other parts of appveyor.yml?
Btw, another idea would be having support for something like
appveyor.<branch>.yml! How about that, can you see any potential issues with this approach? :)
4 Posted by jffelsinger on 03 Jun, 2014 07:18 PM
I don't think my team would need branch-specific settings elsewhere. Just the configurations would be dandy. As far as the branch-specific appveyor.yml files go, I don't see a problem with that one either; it'd be pretty cool.
Though, with the separate files approach it might be more flexible to do something like:
appveyor.<arbitrary_name>.yml, then in the file itself allow the user to specify which branch(s) it'd apply to somehow.
(You do really great support, thanks.)
Support Staff 5 Posted by Feodor Fitsner on 03 Jun, 2014 07:30 PM
OK, thanks for your thoughts. I can envision only username as
<arbitrary_name>value. Yes we have user information in every push, but what if two or more devs working on the same branch... looks like those nasty VS
.userfiles in the root of projects :) From technical perspective doing
appveyor.<branch>.ymlis easier and, perhaps, it will look more natural.
...without support such service is pointless. I would say it's not kind of support, but it's more like solving problems, sharing and collecting the experience! I like thinking of AV as a "CI knowledge aggregating platform" which helps other developers to on board faster :)
6 Posted by jffelsinger on 03 Jun, 2014 08:31 PM
Mm, I might have worded that badly. Not really a per-user file per se, but just more decoupled from any one particular branch. I was sort of thinking of a use-case where one might want to use one configuration over a couple different branches.
In which case they could do something like
appveyor.testing.yml, and then supplying in file that it uses this config when building for say... anything that's not a master or release branch, such as dev or feature branches (Maybe just use the functionality for the
branches:setting that's already there?). Then an
appveyor.release.ymlto handle release, master, etc branches.
Though, I don't know if the use-case is realistic in any way. I just thought of it out of concern for clutter. If one wanted to use one config for more than one branch,
appveyor.release.ymlmight be DRYer than
appveyor.<branch_3>.yml, etc. If no one actually needed to re-use the configs it wouldn't be worth the effort, and the easier to implement
appbeyor.<branch>.ymlwould be best, like you said. :)
Support Staff 7 Posted by Feodor Fitsner on 03 Jun, 2014 08:46 PM
OK, makes sense. Then how would we choose desired config when making a push?
8 Posted by jffelsinger on 03 Jun, 2014 09:05 PM
Mmm, good point. If there were two configs where the branches were set,
You could use that, to decide which to use. Push to dev and it would use the config that can build for dev, since it is already implemented and someone could only build on a config where the branch matches anyway.
However, I'm not sure how you would choose if the branches that were setup overlap (like if both were set to build on a push to dev). You could default it to the regular appveyor.yml in such a case, or add a setting for priority, or just pick one of the overlapping yml files arbitrarily. (I do see what you mean about this way being harder to implement if you went with it)
Support Staff 9 Posted by Feodor Fitsner on 03 Jun, 2014 11:53 PM
...or even better we could combine multiple configs in a single
So, if YAML root is a sequence then it has multiple configs, if it's mapping then a single.
Selecting required config could follow these rules:
1) if there is no config with matching
branches/onlyAV will fall back to the config without
2) if there is more than one config matching branch - error
3) if there are no matching configs - build is not started
And branch name could be regex, e.g.
Have I missed something?
10 Posted by jffelsinger on 04 Jun, 2014 12:35 PM
I didn't even think about making the root a sequence, that's a great solution. I think it covers everything too. *thumbs up\*
Support Staff 11 Posted by Feodor Fitsner on 04 Jun, 2014 04:32 PM
Good, will implement this scenario then.
12 Posted by cyberkruz on 10 Jun, 2014 09:19 PM
This would be incredibly helpful for my scenario as well. I have a number of build configurations for different scenarios (production to master, staging to dev, etc), but I'm currently not using appveyor for deployments because it takes to long to have production built every time someone commits to a random pull request branch. There is some amazing thinking here. Will there be updates to the status of this feature in this thread?
PS: Great support by the way.
Support Staff 13 Posted by Feodor Fitsner on 11 Jun, 2014 12:04 AM
Absolutely, we'll keep you guys updated! The deployment story is definitely the next thing we are going to improve.
You can disable pull requests on GitHub webhook or what's the issue you're currently experiencing? Could you please elaborate?
14 Posted by cyberkruz on 11 Jun, 2014 12:55 AM
We do all our development through pull requests (we love the GitHub webhook). The hiccup is our solution has a number of build configurations to do config transforms (Debug, Release, Testing, Live). My end goal is to have AppVeyor build all of the pull requests under Debug (any branch that isn't dev or master) like it currently is. When the pull requests are merged into the dev branch they would automatically build and deploy to our Azure testing server using the Testing build configuration. When dev is tested and merged into master it would automatically deploy to our Azure production Staging instance using the Live build configuration.
Currently to do this we either have to make multiple projects (like traditional ci servers) or have AppVeyor build every build configuration every time which takes a bit too long. Something like this would be killer:
or even like you guys were talking about before:
I think either one of those scenarios would solve my use case. Does this make sense or am I not explaining correctly. Sorry about the wall of text.
Support Staff 15 Posted by Feodor Fitsner on 11 Jun, 2014 03:39 AM
Yes, that makes sense! Thanks for explaining your use case. It could be cool to include these examples into documentation when the feature is ready. I think we'll deliver it this week.
Support Staff 16 Posted by Feodor Fitsner on 13 Jun, 2014 05:09 AM
OK, the feature has been implemented and deployed. Give it a try and let me know what you think! ;)
17 Posted by cyberkruz on 13 Jun, 2014 11:12 PM
I tried out the feature, and I am having a problem. It will not build dev or master for some reason. I tried to be as explicit as possible with the configuration. Let me know if I am configuring this correctly or not. Also, is there a way I can debug appveyor.yml configuration problems so I can give you better information? Here is my config:
Support Staff 18 Posted by Feodor Fitsner on 13 Jun, 2014 11:29 PM
Make sure you have the same
appveyor.ymlin all branches. When you kick of a build of specific branch AppVeyor is downloading appveyor.yml from that branch.
19 Posted by cyberkruz on 14 Jun, 2014 08:29 AM
Thank you so much. I think I am almost there. It looks like every time that I commit to a branch everything builds and works perfect. Whenever I commit to the dev branch directly it publishes correctly. Awesome work by the way. The only problem is that when I create a pull request from a branch to dev it is building the request under dev instead of the branch. This triggers a publish to the server every time someone creates a request (as well as when we accept the request). I think this is actually intended behavior it would be nice if the publish didn't happen on the request only on the merge. I think until then I am going to just have a third branch (staging) that I merge dev into which will publish to stage.
20 Posted by cyberkruz on 14 Jun, 2014 08:45 AM
For the record, here is my final yml file for your documentation:
PS: Thank you so much for your continued work on this. Me and everyone at Rentler appreciates it. I plan on writing an article, and I will link to it in case you are interested.
21 Posted by charles on 03 Oct, 2014 01:57 PM
It would be nice of we could only override some settings. For example, in my project I have the branch
master. I would like to be able to specify some settings specific to each branch, something like it, I am not a YML expert, I don't even know if this is valid YML:
All other settings are the same for both
Support Staff 22 Posted by Feodor Fitsner on 03 Oct, 2014 07:06 PM
That's valid suggestion. Will give it a thought. Thanks!
23 Posted by calinoiu.alexan... on 07 Apr, 2016 07:28 PM
Was this ever implemented? Can you point me to the documentation please?
Support Staff 24 Posted by Feodor Fitsner on 07 Apr, 2016 07:30 PM
This is it: http://www.appveyor.com/docs/branches#conditional-build-configuration
25 Posted by calinoiu.alexan... on 11 Apr, 2016 01:14 PM
I can't seem to be able to figure this out, I need to run the build with a different env variable for each branch
So far I have:
But none of my install and before filters fire.
Support Staff 26 Posted by Feodor Fitsner on 11 Apr, 2016 01:30 PM
Because you have to repeat the entire configuration for every branch.
27 Posted by calinoiu.alexan... on 11 Apr, 2016 01:32 PM
I see, it will be great not to that.
Support Staff 28 Posted by Feodor Fitsner on 11 Apr, 2016 01:34 PM
Yeah, there is an item for that: https://github.com/appveyor/ci/issues/325
Ilya Finkelshteyn closed this discussion on 25 Aug, 2018 02:05 AM.