It won't be a failure of the package already exists - AppVeyor will just skip its deployment.

• Feodor

On Thu, Jun 4, 2015 at 11:44 AM, nulltoken notifications@github.com
wrote:

Cross platform compatibility is ensured as part of the Pull Request lifecycle. Both Travis and AppVeyor should be green before a PR merged. Would the merge build fail, it would only be because of a network hiccup (which could be re-triggered in order to display green badges on the README).
This is an attempt at automating the NuGet publication.
If the appveyor tweaking is correct, upon a successful merge, the generated NuGet package will be automatically deployed.
Currently, only vNext and master branches are monitored by AppVeyor:

• vNext: produces prerelease packages
• master: produces stable packages
  Some issues I can think of about this proposal:
• Usage of the matrix: I'm under the impression that each job will trigger the deployment.
• Would someone trigger a rebuild of a merged commit, how to avoid the repeated publication of the NuGet package? FWIW, I don't know for sure how nuget.org reacts to this, but I suspect that this should lead to some failure, which in turn would fail the build.
  /cc @FeodorFitsner
  You can view, comment on, or merge this pull request online at:
  #1073
  -- Commit Summary --

  • Automate NuGet deployment on merge
    -- File Changes --
    M appveyor.yml (9)
    -- Patch Links --
    https://github.com/libgit2/libgit2sharp/pull/1073.patch
    https://github.com/libgit2/libgit2sharp/pull/1073.diff

    Reply to this email directly or view it on GitHub:
    #1073

@FeodorFitsner Thanks!

Thoughts:

• Do not use the current build datetime as the pre-release package suffix (as they would differ on the x86 and amd64 jobs)
• Use the merge commit datetime (As we now prefer using GitHub UI for merges, it should be safe to rely on this datetime, as it always will be incrementing). This should still allow NuGet to consider each new prerelease package as more recent than the previous ones.
• The merge commit timestamp is currently exposed by AppVeyor through the APPVEYOR_REPO_COMMIT_TIMESTAMP environment variable
• A tiny problem is that the current variable content looks ambiguous with regards to UTC/local eg. 9/5/2014 1:06:05 PM. (cf. appveyor/ci#289).