Different deployment strategies on different branches

This discussion is public.

asbjorn's Avatar

asbjorn

15 Nov, 2016 09:58 PM

In a project, we would like to deploy all commits on the `develop` branch to NuGet (as prerelease packages) and all tagged commits on the `master` branch. We shouldn't have tags on other branches than master, but it's not guaranteed to not happen, so we don't want to deploy all tagged commits regardless of branch.

I seem to be unable to implement this deployment strategy in `appveyor.yml`. Is it at all possible? What I'm having most problems with is that AppVeyor seems to conflate the `tag` and `branch` concepts, so when a tag is built, the `branch` variable is set to the name of the tag and not the branch.

Since both branch and tag references are just disconnected references in Git, I can understand this design choice, but in the real world, it doesn't really work. Most people view commits that have both a branch and tag reference pointing to it to indicate that the tag "is" on the branch, although it from Git's point of view, isn't.

It also seems wasteful that AppVeyor builds the same commit ID for both the tag and the branch reference, instead of merging these two together, as I expect most people would want and expect as well.

  1. 1 Ilya Finkelshteyn's Avatar Ilya Finkelshteyn on 15 Nov, 2016 11:08 PM

    Hello,

    If you check GitHub webhook (under Settings / Webhooks / <appveyor_webhook> /scroll down to Recent deliveries) you can see that there are no branch name in webhook related to tag, but tag name shown as branch. Therefore there is no way for us to distinguish tagged commits between branches. The only thing I can think of is that you can establish some naming convention for tags in different branches and filter tags based on those naming conventions.

    --ilya.

  2. 2 asbjorn's Avatar asbjorn on 15 Nov, 2016 11:43 PM

    Ah, so the problem originates from GitHub. I see. Yes, we will have to be diligent with what we tag and where, then. Thanks.

  3. 3 asbjorn's Avatar asbjorn on 16 Nov, 2016 10:23 AM

    But I still wonder how I can structure my appveyor.yml file to have different deploy strategies based on which branch is being built. The following article lines out how it can look like, but I'm unable to get it to work:

    https://www.appveyor.com/docs/branches/

    As mentioned, I want pre-release packages deployed from every commit to the develop branch and stable packages deployed from tags (on the master branch). How do I configure this?

  4. 4 Ilya Finkelshteyn's Avatar Ilya Finkelshteyn on 17 Nov, 2016 03:12 AM

    Here is sample from YAML which works for me.

    # this is not directly related to your question just nice way to make pre-release versions.
    after_build:
    - ps: if ($env:APPVEYOR_REPO_TAG -eq $true) {dotnet pack src\dotnetcore-nuget -o .\Artifacts} else {dotnet pack src\dotnetcore-nuget -o .\Artifacts --version-suffix=$env:APPVEYOR_BUILD_NUMBER}
    
    artifacts:
    - path: .\Artifacts\*
    
    # settings are the same for  both Nuget providers, except "on:" condition
    deploy:
    - provider: NuGet
      ...
      on:
        branch: develop
    - provider: NuGet
      ...
      on:
        appveyor_repo_tag: true
    

    This will deploy on any tag, not only on master, but this is because of webhook content as we already discussed.

    Note that if deployment do not happen you will see 2 messages:

    "NuGet" deployment for branch "develop" has been skipped because current branch is "master"
    "NuGet" deployment has been skipped as environment variable has not matched ("appveyor_repo_tag" is "false", should be "true")
    
    But in case deployment happened either because of branch or because of tag, you will still see one (but only one) of those messages.

    Hope this makes sense.

    --ilya.

  5. 5 asbjorn's Avatar asbjorn on 18 Nov, 2016 01:48 PM

    Ah, so each provider can be repeated. I see. It would then be nice if common stuff could be moved up a level or somewhere else, so we avoid repetition. I'll test this out and report status back.

    Regarding prerelease version numbers, I mostly use GitVersion to ensure that:

    https://github.com/GitTools/GitVersion/

  6. Ilya Finkelshteyn closed this discussion on 25 Aug, 2018 02:09 AM.

Comments are currently closed for this discussion. You can start a new one.