Move CI over to AppVeyor

[PureKrome]

First mentioned in this conversation: https://github.com/garethdown44/nbuilder/pull/35

I'm happy to take the reigns on this. I've done a number of OSS projects using AV to publish to myget (for dev) then nuget (for live).

If the collabs are happy with this, I can talk about my suggetsions (high level / how I automate the version numbers / why 2 feeds, etc).

else close this issue :+1:

[crmckenzie]

I'd like to see this happen as the OSS teamcity server is really slow and apparently no longer has all of the dependencies we need.

I have an appveyor build setup for my Odin project which publishes a beta version to nuget.org if the commit is on a release branch and a release version when the commit is on master. I think a safer approach would be to stall the release version until there's a release tag on master.

Success Criteria

1. Build and Test NBuilder against the 4.0 framework
2. Bulid and Test NBuilder against the 3.5 framework
3. Build and Test NBuilder against the SL4 framework
4. Build the nuget package
5. Publish a beta version to nuget.org (or maybe just appveyor's internal feed) when the branch begins with release/*
6. Publish a release version to nuget.org when the branch is master and the commit is tagged release-*

What are you thoughts? Let's get agreement on acceptance criteria before we do any real work :)

[PureKrome]

Let's get agreement on acceptance criteria before we do any real work :)

totally :)

I'd like to see this happen as the OSS teamcity server is really slow and apparently no longer has all of the dependencies we need.

sweet! lets chat then...

publishes a beta version to nuget.org if the commit is on a release branch and a release version when the commit is on master.

Ok - this is very similar to what I do ... with a minor change. I don't publish my pre-releases to nuget.org because i don't like polluting that feed with lots of branches before a release. Sure, if there's only one or two PR's a year. np. But I just don't like that habit.

I'll explain what I do and why.

master

master branch is ONLY for releases to nuget.org. The version is controlled via the AppVeyor-master.yml file. generally, the minor version is incremented only. Major version number's are a serious thing, so I would update the AV-master.yml file with that number. Besides that, it uses the AV {build} number.

dev

dev is the official branch for any PR's to be accepted but any branch name can be used if we're trying stuff out, etc. CI looks for !master branches and kicks off. in deploys to MyGet.org (which is free/public) and is a pre-release .. so the version number prepended with -dev to keep semver happy. I personally use the patch number (in a version) so it closely syncs with the next public nuget (master) release. This is again handled magically in the AppVeyor.yml (notice this is a different yml file).

So why bother? This is the testing ground. For each successful commit that is pushed up to upstream, a nuget file is created and pushed to this testing / proving ground. You would be surprised how many times file get pushed to this place. A lot of the time, people don't use most of these packages from myget. Fine. i get that. The point is that the OPTION is there if we need to test just one of these pre-releases out and there is a system now in place to throw that stuff up there auto-magically.

and the main nuget feed isn't polluted.

Finally, i would drop support for SL4 and 3.5. meh! Keep things simple.

that's my 2c. :smile:

:money_with_wings:

Edit 1:

sample projects doing this:

• SimpleAuthentication
• OpenRealEstate
• SimpleSiteMap

Edit 2:

Nice work in your av.yml file! all three scenario's all in one file. I could never figure out how to do them all, in one file.

[crmckenzie]

I wouldn't want to drop the older framework support without @garethdown44 's explicit consent. The last time he & I worked together on NBuilder he was pretty solid on keeping support for the other frameworks.

I imagine before too long we'll want to support the "Core" framework in addition to 4.0+. That's something to consider. I haven't seen this done with AppVeyor yet.

Question: Why use myget for beta's instead of appveyor's built-in feed? I'm not against it necessarily, I'm just wondering why?

Otherwise I think we're on the same page with respect to how this should work, though I daresay you are probably more advanced with Appveyor than I am. I look forward to catching up with you. :)

[PureKrome]

I wouldn't want to drop the older framework support without @garethdown44 's explicit consent.

NP.

I imagine before too long we'll want to support the "Core" framework

I'm biting at the chomp for vnext. So i'll be all over updating OSS stuff to re-sync with .NET Core.

Why use myget for beta's instead of appveyor's built-in feed?

• I've never seen any obvious info about how to access the packages on there.
• Is there a GUI for easy discoverability? (myget has this)
• Not phased either way. Just would like some website landing page to be able to see the feed content without having to use Nuget package manager to see the feed info. (discoverability)

Schaweet!

[crmckenzie]

It just creates an endpoint which you can use with the nuget exe. There's no integrated UI other than what you get in Visual Studio that I can see.

What do you need from me to get started on this?

[PureKrome]

There's no integrated UI other than what you get in Visual Studio that I can see.

so ... want to use myget then? your call. (remember, needs to be easy for developers to find/discover the -pre packages...

[crmckenzie]

I can't say I feel strongly about it either way. Honestly, Semantic Versioning is much more important to me. Using MyGet is fine with me.

[crmckenzie]

Where do we stand on this? Anything I can do to help?

[PureKrome]

Yo! Hi!

i'll try and give this a crack in the next few days -> i'll PR up an AV file or something... watch this space :)

[PureKrome]

Hi team.

whoa. EPIC :/

So i've probably invested about 10 hours into this issue. (yes, i said 10). I've levelled up from a AppVeyor-Veteran to AppVeyor-Ninja-God-Asshat.

Basically, the fact that there's multiple frameworks was the problem.

But i've done it.

But first!! there's some admin stuff I need to sort out. I'll explain what been set up and what the repo owners need to do to take ownership of the parts i've setup.

I've setup the following:

• A free account with AppVeyor.
• A free account with myget.
• Created a fork with the appveyor.yml settings

With AV, there's two projects in there.

• master
• !master

So the flow is this:

• All work is done in custom forks and then PR'd up to upstream/dev and ONLY dev branch. (upstream is this repo .. while origin's are your forks). I'm assuming you guys know the what i mean by upstream and origin.
• When a PR is submitted to dev branch, AV kicks off and does it stuff.
• When the PR is accepted/merged, AV kicks off again and this time publishes a nuget package to myget. Following semver the build number is postpended with -dev so it's then viewed as a pre-release package.
• Once the nuget package has been tested (assuming the PR is not a tiny thing and warrants testing), you then PR from dev -> master.
• AV kicks off again against master but does not deploy.
• Master is accepted/merged, and AV kicks off for the last time and if all good, finally deploys the nuget package to nuget.org. As a proper release.

Now, lets talk about the nuget package...

this contains THREE dll's.

\_ NET40
\_ NET35
\_SL4

I couldn't get SL3 to compile or work. Care factor zero, from me with regards to SL3.

I also couldn't get the SL4 unit tests to work either. Again, this is SL ... so care factor == zero.

And finally, I upgraded the project and solution to work with VS2015 because .. well.. we should all be on that by now (especially when there's a working free version, now).

Work required by Admins

• I need to give you the usernames/password to both AV and MG. (same password) and you guys need to take ownership of them, IMO.

I'm not sure if i should paste them here and you guys quickly change em OR i can email them or use twitter DM's, etc. I'm kewl with whatever.

If that sounds sounds all peachy to you gentle folk, then i'll submit my PR. for review.

now, some cat tax:

[PureKrome]

oh - another thing i forgot to mention.

with this being on AV, i've dropped all this nant and travis :shit:. No need for the 80's to :phone: us up. Powershell is your father.

[crmckenzie]

@PureKrome, let me say "Thank You" for the work you've done on this. I won't be able to look deeply at this for a few days, but it's my highest priority on this project. Talk to you soon!

[PureKrome]

@crmckenzie great! also - how would you like the secret info handed over?

[crmckenzie]

I've been working on this too, though I think you have gotten much farther than I have.

I've setup the following:

• A free account with AppVeyor.
• A free account with myget.
• Created a fork with the appveyor.yml settings

I have an AppVeyor account already. I'll be reaching out to AppVeyor to see if we can create an nbuilder organization account so that it's not directly associated with my username. I'd like to do the same thing with MyGet. If I do it correctly, it should not be necessary for you to transfer your accounts to us. I think accepting your AppVeyor.yml files and associated build scripts into the project should be sufficient as far as that goes.

With AV, there's two projects in there.

master !master

Just FYI, I plan to enhance this somewhat. I would like to use Git Flow as the branching strategy. I would like all commits on all branches to trigger a CI build. I would like "release/*" branches to trigger a beta-package publish. I would like merges to master to trigger the release package publish. As you wrote, PR's would be accepted into the upstream "develop" branch.

I am not asking you to do this additional work.

I couldn't get SL3 to compile or work. Care factor zero, from me with regards to SL3.

@garethdown44 and I have previously agreed to no longer support SL3. We will continue to support SL4. I will take on the task of getting the SL4 tests to work. I think I know what issue you encountered and I've resolved it before. Later I will migrate from SL4 to SL5. After the world has moved on to the Core Framework, my guess is that SL5 will atrophy as well.

I need to give you the usernames/password to both AV and MG. (same password) and you guys need to take ownership of them, IMO.

I don't think you do. I already have an AV account and myget account. I'll reach out to both providers to see about creating an organization account for nbuilder so that the projects are not stuck under my username. If you still feel like you should you can send the credentials to me at crmckenzie(at)gmail

All I need from you is your PR. I'll merge it into "develop" and get the account process started with the AV and MyGet.

Let me say "Thank You" again for figuring this out. The work you've done is foundational to the continued growth of NBuilder.

I look forward to your PR. Let me know if you need anything else from me, or anything I said did not make sense.

[crmckenzie]

Hey @PureKrome, where do we stand on the PR? I'm looking forward to marking this issue closed.

[PureKrome]

I need an email address or a twitter handle i can DM some of the private info to (eg. u/p for the services). then i can start to post stuff up/pr.

[crmckenzie]

Did you see my earlier comments? I don't think that will be necessary, but if you're convinced it is you can email me using my github handle (at)gmail.com.

Thanks!

[PureKrome]

yep - i read them but i was hoping to get the info to you in the mean time and then you can migrate etc in your time.

baby steps, etc.

on it now!

[crmckenzie]

sweet!

[PureKrome]

For those reading this thread - email sent to @crmckenzie :+1:

[PureKrome]

@crmckenzie ready to PR now.

Can you please make a dev branch in this repo, please. so i can PR to that... starting my flow and it tests my AV yml file(s).

[crmckenzie]

done. I look forward to your PR.

[PureKrome]

@crmckenzie Take note with this PR:

• Your commit 82011b3afe7d68fa15416c4b2c2d5d49c932873b which added a CI AV badge for your AV has been removed / undone.
• New badges have been made.
• The icons for some of the badges will not work/display UNTIL the AV project has actually completed. (eg. AV-master project has no build yet made, so it will display a broken badge until we PR + merge to master).
• I've not removed any of the old ps1 files used for building stuff. I was going to leave this for you, as i'm not toooo sure where these are still being used outside of AV. eg. do people use that to manually build on their own localhost? I see that these ps1 files (eg.`Invoke-NuGetpack.ps1) i think should be removed because AV handles all of this, now.

[PureKrome]

@crmckenzie Yo :) i've just checked the dev branch and noticed that the readme.md is saying that AV is failing. clicking the 'av badge' in the readme, it bounces over to AV and lists an error.

The error looks like that, that CI project is not picking up the AV project and is auto-trying to locate the sln's to build.

Do you need some help with this?

Try checking the settings for your AV project ... should look like this...

for NBuilder (release/*): value should be AppVeyor/appveyor.yml. for NBuilder (master) : value should be AppVeyor/appveyor-master.yml

[crmckenzie]

Thanks for noticing, but I'll tend to it when it gets closer to release time (which is close!). I think the readme may just be pointing to the wrong build or something.

Appveyor says it's currently building