🎉 👍

@whoisj It's not there yet... 😉

oh I was commenting on the concept - not actually approving anything 😕

@FeodorFitsner I think I'd need some help from you with this PR 🙏

How can publish the file libgit2sharp.zip as an artifact?

038e962 doesn't publish it.
Neither 5459aef

Although it exists in the folder (see the ls output in the build log)

I'm surely missing something obvious here, your insight would be very much appreciated.

When is libgit2sharp.zip created? Artifacts are getting packaged after test and before deploy stages. Maybe you should use script to push artifacts: http://www.appveyor.com/docs/packaging-artifacts#pushing-artifacts-from-scripts

Artifacts are getting packaged after test and before deploy stages.

@FeodorFitsner Perfect! They're currently created in the on_success stage. I'm going to move this to build_success, then.

As always, you're spot on with an amazing support. ❤️ ‼️

@FeodorFitsner s/build_success/deploy_script/

@FeodorFitsner I eventually relied on after_test (BTW, maybe the doc should mention that this after_* hooks are invoked if the related stage succeeded.

@csMACnz PublishCoverity is awesome!

However, Coverity may reject a build because the maximum number of uploaded builds has been exceeded. How could we nicely wrap the call to PublishCoverity.exe publish so that it doesn't fail the AppVeyor build when that happens?

For instance, this current builds fails because the AppVeyor secured variables aren't valued in a PR. According to you, how should we tweak the script so that the build doesn't fail any more?

/cc @FeodorFitsner

Can we limit Covertity to only run after all other unit tests pass?

@whoisj The tests are currently commented out to speed the build. Of course, they'll be reinstated once I'm done and this PR is ready for review.

@whoisj I took an alternate route.

AppVeyor exposes a way to schedule builds.

New proposal is to run Coverity once a week during a scheduled build. As the build will be a re-run of the the latest vNext tip, there's no need to run the tests any longer (this saves us from failed builds because of network hiccups).

Thoughts?

That works so long as somebody is responsive to the Covertity report and creates issues appropriately; and release points are at, or as close as reasonable to, Covertity scan points.

That works so long as somebody is responsive to the Coverity report and creates issues appropriately; and release points are at, or as close as reasonable to, Covertity scan points.

Indeed, the idea would be to fix them as quickly as possible.
FWIW, the way it's configured, found defects are not disclosed by default.

So, good people, good to merge?

👍