tag:help.appveyor.com,2012-11-13:/discussions/suggestions/232-conditional-build-confirgurationAppVeyor: Discussion 2018-08-25T02:05:40Ztag:help.appveyor.com,2012-11-13:Comment/332533792014-06-03T18:19:22Z2014-06-03T18:19:22ZConditional build confirguration<div><p>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:<br></p>
<pre>
<code>configuration:
- Release
- Debug</code>
</pre>
<pre>
<code>deploy:
- provider: Environment
name: My Environment
on:
branch: dev
configuration: Debug</code>
</pre>
<p>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:</p>
<pre>
<code>configuration:
- name: Release
on:
branch: master
- name: Debug
on:
branch: dev</code>
</pre>
<p>This would save some time, not having to build both
configurations when only one is needed.</p></div>jffelsingertag:help.appveyor.com,2012-11-13:Comment/332533792014-06-03T18:46:16Z2014-06-03T18:46:16ZConditional build confirguration<div><p>Why couldn't you have a specific appveyor.yml for every branch?
For example, you can commit appveyor.yml in "dev" branch with
<code>configuration: debug</code> only.</p></div>Feodor Fitsnertag:help.appveyor.com,2012-11-13:Comment/332533792014-06-03T18:56:49Z2014-06-03T18:57:40ZConditional build confirguration<div><p>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).</p></div>jffelsingertag:help.appveyor.com,2012-11-13:Comment/332533792014-06-03T19:03:00Z2014-06-03T19:03:00ZConditional build confirguration<div><p>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.</p>
<p>Build matrix and deployment is one thing. Do you need
branch-specific settings for other parts of appveyor.yml?</p>
<p>Btw, another idea would be having support for something like
<code>appveyor.<branch>.yml</code>! How about that, can you
see any potential issues with this approach? :)</p></div>Feodor Fitsnertag:help.appveyor.com,2012-11-13:Comment/332533792014-06-03T19:18:19Z2014-06-03T19:18:19ZConditional build confirguration<div><p>I don't think <em>my team</em> 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.</p>
<p>Though, with the separate files approach it might be more
flexible to do something like:
<code>appveyor.<arbitrary_name>.yml</code>, then in the file
itself allow the user to specify which branch(s) it'd apply to
somehow.</p>
<p>(You do <em>really great</em> support, thanks.)</p></div>jffelsingertag:help.appveyor.com,2012-11-13:Comment/332533792014-06-03T19:30:47Z2014-06-03T19:30:47ZConditional build confirguration<div><p>OK, thanks for your thoughts. I can envision only username as
<code><arbitrary_name></code> 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 <code>.user</code>
files in the root of projects :) From technical perspective doing
<code>appveyor.<branch>.yml</code> is easier and, perhaps, it
will look more natural.</p>
<p>...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 :)</p></div>Feodor Fitsnertag:help.appveyor.com,2012-11-13:Comment/332533792014-06-03T20:31:02Z2014-06-03T20:31:02ZConditional build confirguration<div><p>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.</p>
<p>In which case they could do something like
<code>appveyor.testing.yml</code>, 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 <code>branches:</code> setting
that's already there?). Then an <code>appveyor.release.yml</code>
to handle release, master, etc branches.</p>
<p>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,
<code>appveyor.testing.yml</code> and
<code>appveyor.release.yml</code> might be DRYer than
<code>appveyor.<branch_1>.yml</code>,
<code>appveyor.<branch_2>.yml</code>,
<code>appveyor.<branch_3>.yml</code>, etc. If no one actually
needed to re-use the configs it wouldn't be worth the effort, and
the easier to implement <code>appbeyor.<branch>.yml</code>
would be best, like you said. :)</p></div>jffelsingertag:help.appveyor.com,2012-11-13:Comment/332533792014-06-03T20:46:06Z2014-06-03T20:46:06ZConditional build confirguration<div><p>OK, makes sense. Then how would we choose desired config when
making a push?</p></div>Feodor Fitsnertag:help.appveyor.com,2012-11-13:Comment/332533792014-06-03T21:05:10Z2014-06-03T21:06:03ZConditional build confirguration<div><p>Mmm, good point. If there were two configs where the branches
were set,</p>
<p>appveyor.config_1.yml<br></p>
<pre>
<code>branches:
only:
- dev
- testing</code>
</pre>
<p>appveyor.config_2.yml<br></p>
<pre>
<code>branches:
only:
- master
- release
# or
except:
- dev
- testing</code>
</pre>
<p>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.</p>
<p>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)</p></div>jffelsingertag:help.appveyor.com,2012-11-13:Comment/332533792014-06-03T23:53:02Z2014-06-03T23:53:02ZConditional build confirguration<div><p>...or even better we could combine multiple configs in a single
<code>appveyor.yml</code> like that:</p>
<pre>
<code># first config
-
branches:
only: master
# second config
-
branches:
only:
- dev
- qa</code>
</pre>
<p>So, if YAML root is a sequence then it has multiple configs, if
it's mapping then a single.</p>
<p>Selecting required config could follow these rules:<br>
1) if there is no config with matching <code>branches/only</code>
AV will fall back to the config without <code>branches/only</code>
section defined.<br>
2) if there is more than one config matching branch - error<br>
3) if there are no matching configs - build is not started</p>
<p>And branch name could be regex, e.g. <code>/dev.*/</code> or
<code>/feature-.*/</code>.</p>
<p>Have I missed something?</p></div>Feodor Fitsnertag:help.appveyor.com,2012-11-13:Comment/332533792014-06-04T12:35:09Z2014-06-04T15:47:55ZConditional build confirguration<div><p>I didn't even think about making the root a sequence, that's a
great solution. I think it covers everything too. <em>*thumbs
up\</em>*</p></div>jffelsingertag:help.appveyor.com,2012-11-13:Comment/332533792014-06-04T16:32:29Z2014-06-04T16:32:29ZConditional build confirguration<div><p>Good, will implement this scenario then.</p></div>Feodor Fitsnertag:help.appveyor.com,2012-11-13:Comment/332533792014-06-10T21:19:51Z2014-06-10T21:19:53ZConditional build confirguration<div><p>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?</p>
<p>PS: Great support by the way.</p></div>cyberkruztag:help.appveyor.com,2012-11-13:Comment/332533792014-06-11T00:04:03Z2014-06-11T00:04:03ZConditional build confirguration<div><p>Absolutely, we'll keep you guys updated! The deployment story is
definitely the next thing we are going to improve.</p>
<p>You can disable pull requests on GitHub webhook or what's the
issue you're currently experiencing? Could you please
elaborate?</p></div>Feodor Fitsnertag:help.appveyor.com,2012-11-13:Comment/332533792014-06-11T00:55:06Z2014-06-11T00:55:07ZConditional build confirguration<div><p>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.</p>
<p>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:</p>
<pre>
<code>-
branches:
except:
- master
- dev
configuration: Debug
-
branches:
only: dev
configuration: Testing
build:
publish_azure: true
# stage deployment details
-
branches:
only: master
configuration: Live
build:
publish_azure: true
# live deployment details</code>
</pre>
<p>or even like you guys were talking about before:</p>
<pre>
<code>configuration:
name: Live
on:
branch: master</code>
</pre>
<p>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.</p></div>cyberkruztag:help.appveyor.com,2012-11-13:Comment/332533792014-06-11T03:39:13Z2014-06-11T03:39:13ZConditional build confirguration<div><p>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.</p></div>Feodor Fitsnertag:help.appveyor.com,2012-11-13:Comment/332533792014-06-13T05:09:24Z2014-06-13T05:09:24ZConditional build confirguration<div><p>OK, the feature has been implemented and deployed. Give it a try
and let me know what you think! ;)</p></div>Feodor Fitsnertag:help.appveyor.com,2012-11-13:Comment/332533792014-06-13T23:12:56Z2014-06-13T23:12:57ZConditional build confirguration<div><p>Hi there!</p>
<p>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:</p>
<pre>
<code>-
shallow_clone: true
version: 3.7.{build}
branches:
except:
- master
- dev
configuration: Debug
before_build:
- cmd: cd src
- cmd: nuget restore
- cmd: cd ..
build:
project: src/MyProject.sln
verbosity: minimal
-
shallow_clone: true
version: 3.7.{build}
branches:
only: dev
configuration: Staging
before_build:
- cmd: cd src
- cmd: nuget restore
- cmd: cd ..
build:
project: src/MyProject.sln
verbosity: minimal
#publish_azure: true
-
shallow_clone: true
version: 3.7.{build}
branches:
only: master
configuration: Live
before_build:
- cmd: cd src
- cmd: nuget restore
- cmd: cd ..
build:
project: src/MyProject.sln
verbosity: minimal
#publish_azure: true</code>
</pre></div>cyberkruztag:help.appveyor.com,2012-11-13:Comment/332533792014-06-13T23:29:02Z2014-06-13T23:29:02ZConditional build confirguration<div><p>Make sure you have the same <code>appveyor.yml</code> in all
branches. When you kick of a build of specific branch AppVeyor is
downloading appveyor.yml from that branch.</p></div>Feodor Fitsnertag:help.appveyor.com,2012-11-13:Comment/332533792014-06-14T08:29:36Z2014-06-14T08:29:37ZConditional build confirguration<div><p>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.</p></div>cyberkruztag:help.appveyor.com,2012-11-13:Comment/332533792014-06-14T08:45:23Z2014-06-14T08:45:24ZConditional build confirguration<div><p>For the record, here is my final yml file for your
documentation:</p>
<pre>
<code>#
# Current setup:
# - All development is done in a branch off dev
# - Pull requests are merged into dev
# - When publishing to stage we just merge dev to stage
# and it auto publishes to the stage server
# - When publishing to master we just merge stage
# to master and it auto publishes to production
#
-
shallow_clone: true
version: 3.7.{build}
branches:
except:
- master
- stage
configuration: Debug
before_build:
- cmd: cd src
- cmd: nuget restore
- cmd: cd ..
build:
project: src/MyProject.sln
verbosity: minimal
-
shallow_clone: true
version: 3.7.{build}
branches:
only:
- stage
configuration: Staging
before_build:
- cmd: cd src
- cmd: nuget restore
- cmd: cd ..
build:
project: src/MyProject.sln
verbosity: minimal
publish_azure: true
assembly_info:
patch: true
file: AssemblyInfo.*
assembly_version: "{version}"
assembly_file_version: "{version}"
assembly_informational_version: "{version}"
deploy:
provider: AzureCS
subscription_id: super-cool-subscription-id
subscription_certificate: +LSKDJFLJNL
storage_account_name: mystoragestage
storage_access_key:
secure: blehiBlhe==
service: myservicestage
slot: production
-
shallow_clone: true
version: 3.7.{build}
branches:
only:
- master
configuration: Live
before_build:
- cmd: cd src
- cmd: nuget restore
- cmd: cd ..
build:
project: src/MyProject.sln
verbosity: minimal
publish_azure: true
assembly_info:
patch: true
file: AssemblyInfo.*
assembly_version: "{version}"
assembly_file_version: "{version}"
assembly_informational_version: "{version}"
deploy:
provider: AzureCS
subscription_id: super-cool-subscription-id
subscription_certificate: +LSKDJFLJNL
storage_account_name: mystorage
storage_access_key:
secure: blehiBlhe==
service: myservice
slot: staging</code>
</pre>
<p>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.</p></div>cyberkruztag:help.appveyor.com,2012-11-13:Comment/332533792014-10-03T13:57:00Z2014-10-03T13:57:00ZConditional build confirguration<div><p>It would be nice of we could only override some settings. For
example, in my project I have the branch <code>staging</code> and
<code>master</code>. 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:</p>
<pre>
<code>branches
only:
- staging
configuration: Staging
- master
configuration: Production</code>
</pre>
<p>All other settings are the same for both <code>staging</code>
and <code>master</code> branches.</p></div>charlestag:help.appveyor.com,2012-11-13:Comment/332533792014-10-03T19:06:43Z2014-10-03T19:06:43ZConditional build confirguration<div><p>That's valid suggestion. Will give it a thought. Thanks!</p></div>Feodor Fitsnertag:help.appveyor.com,2012-11-13:Comment/332533792016-04-07T19:28:24Z2016-04-07T19:28:24ZConditional build confirguration<div><p>Hi,</p>
<p>Was this ever implemented? Can you point me to the documentation
please?</p></div>calinoiu.alexandrutag:help.appveyor.com,2012-11-13:Comment/332533792016-04-07T19:30:21Z2016-04-07T19:30:21ZConditional build confirguration<div><p>This is it: <a href="http://www.appveyor.com/docs/branches#conditional-build-configuration">
http://www.appveyor.com/docs/branches#conditional-build-configuration</a></p></div>Feodor Fitsnertag:help.appveyor.com,2012-11-13:Comment/332533792016-04-11T13:14:55Z2016-04-11T13:14:55ZConditional build confirguration<div><p>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</p>
<p>So far I have:</p>
<pre>
<code>-
branches:
only:
- master
configuration: Debug
environment:
APPSETTING_Data:ConnectionStrings:TestConnectionString:
secure: eX93C8dC7qTMkH9/IYKwpGwhGxbYtQzuByKRgYv5Zx47Qt8ZiWm1yD83KZnjUSClX+7r2DwyzXHOdqnxukQjKgq5WbxiWzR+jjQXRdD5CijZ3K6Iikztgpum2suizIaj0I0fIbKhyMnAPN+/VRTMsvukwGLlm1cSPZt47nfk9/0P7B+YfCxE/CmpCBcQl63Sh5MnVUddWfA5A4r3kg0QTXh+6DXfETxfYHN8277cF7w=
-
branches:
only:
- staging
configuration: Release
environment:
APPSETTING_Data:ConnectionStrings:TestConnectionString:
secure: eX93C8dC7qTMkH9/IYKwpGwhGxbYtQzuByKRgYv5Zx47Qt8ZiWm1yD83KZnjUSClAlBrKla4ZFCKBcz6UV1ruY4uW769e1s/ERUmi6e+VsF3gYdN8OrlEA7Dj+blj5JBiN5IcX33iTU8+FFrvDe9TVLmCtNfqL2AHMWgHhyswL5aF83psmsJV7TDbVRqBgBs30omIDJsHQHchXLVUW1oq4pJg0u4sYs0WFtrHaRK2uYqBEW3L6ZYUcWAtHOxkAho
-
configuration: Debug
version: 1.0.{build}
clone_folder: C:\projects\Test2
init:
- ps: Install-Product node $env:nodejs_version
install:
- cmd: >-
npm cache clean -f
npm install -g npm
npm install typescript -g
cd TestWebClient
npm install
cd ..
cache: C:\Users\appveyor\.dnx\packages
before_build:
- cmd: >-
set DNX_BUILD_VERSION=build-%APPVEYOR_BUILD_NUMBER%
dnvm upgrade
dnu restore
build:
project: JLL.Test.V2.sln
publish_wap: true
publish_azure: true
verbosity: minimal
after_build:
- cmd: >-
dnu publish ./TestWebApi --configuration Release -o WebApiOutput --runtime "active" --wwwroot "wwwroot" --wwwroot-out "wwwroot" --iis-command "web" --quiet
TestWebClient\node_modules\.bin\gulp -b "C:\projects\Test2\TestWebClient" --color --gulpfile "C:\projects\Test2\TestWebClient\Gulpfile.js" prepare --env development
dnu publish ./TestWebClient --configuration Release -o WebClientOutput --runtime "active" --wwwroot "wwwroot" --wwwroot-out "wwwroot" --iis-command "web" --quiet
test_script:
- cmd: >-
dnx -p TestDataTests\project.json test
dnx -p TestWebApiTests\project.json test
dnx -p TestBusinessLogicTests\project.json test
dnx -p TestWebApiIntegrationTests\project.json test
TestWebClient\node_modules\.bin\gulp -b "C:\projects\Test2\TestWebClient" --color --gulpfile "C:\projects\Test2\TestWebClient\Gulpfile.js" unit
artifacts:
- path: /WebApiOutput
name: WebApiOutput
- path: /WebClientOutput
name: WebClientOutput
deploy:
- provider: WebDeploy
server: https://Test2-dev-api.scm.azurewebsites.net:443/msdeploy.axd?site=Test2-dev-api
website: Test2-dev-api
username: $Test2-dev-api
password:
secure: LdyiPgW0hHl4Ier4dJR0mk4G4KQJ5m9Rut+J+X9G8WbTxN3mSeePFdkUb9PYr93+5WfV81LbfPSoKq+v1Ihn0A==
artifact: WebApiOutput
aspnet_core: true
remove_files: true
aspnet_core_force_restart: true
on:
branch: master
- provider: WebDeploy
server: https://Test2-dev.scm.azurewebsites.net:443/msdeploy.axd?site=Test2-dev
website: Test2-dev
username: $Test2-dev
password:
secure: UPsN1nGVlmfNgaSY0xcTPdRI2Ko/MyNOSbVFfQG2iKjp4by8lCrUQmdj3eGoFK0c36zVYjdRNa57PDyCiFy4IQ==
artifact: WebClientOutput
aspnet_core: true
remove_files: true
aspnet_core_force_restart: true
on:
branch: master
after_deploy:
- cmd: >-
cd TestWebApi
dnx ef database update -p TestData
dnx seed
notifications:
- provider: Slack
incoming_webhook: https://hooks.slack.com/services/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
channel: Test2
on_build_success: true
on_build_failure: true
on_build_status_changed: false</code>
</pre>
<p>But none of my install and before filters fire.</p></div>calinoiu.alexandrutag:help.appveyor.com,2012-11-13:Comment/332533792016-04-11T13:30:31Z2016-04-11T13:30:31ZConditional build confirguration<div><p>Because you have to repeat the entire configuration for every
branch.</p></div>Feodor Fitsnertag:help.appveyor.com,2012-11-13:Comment/332533792016-04-11T13:32:52Z2016-04-11T13:32:52ZConditional build confirguration<div><p>I see, it will be great not to that.</p>
<p>Alexandru Calinoiu</p>
<p><a href="https://github.com/alexandru-calinoiu/">https://github.com/alexandru-calinoiu/</a></p>
<p><a href="https://ro.linkedin.com/in/alexandrucalinoiu">https://ro.linkedin.com/in/alexandrucalinoiu</a></p></div>calinoiu.alexandrutag:help.appveyor.com,2012-11-13:Comment/332533792016-04-11T13:34:23Z2016-04-11T13:34:23ZConditional build confirguration<div><p>Yeah, there is an item for that: <a href="https://github.com/appveyor/ci/issues/325">https://github.com/appveyor/ci/issues/325</a></p></div>Feodor Fitsner