nbuilder / nbuilder

Rapid generation of test objects in .NET
MIT License
476 stars 85 forks source link

Move CI over to AppVeyor #40

Closed PureKrome closed 8 years ago

PureKrome commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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:

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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

PureKrome commented 8 years ago

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 commented 8 years ago

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:

With AV, there's two projects in there.

So the flow is this:

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'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 commented 8 years ago

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 commented 8 years ago

@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 commented 8 years ago

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

crmckenzie commented 8 years ago

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 commented 8 years ago

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

PureKrome commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

sweet!

PureKrome commented 8 years ago

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

PureKrome commented 8 years ago

@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 commented 8 years ago

done. I look forward to your PR.

PureKrome commented 8 years ago

@crmckenzie Take note with this PR:

PureKrome commented 8 years ago

@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...

image

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

crmckenzie commented 8 years ago

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