kipusoep / UrlTracker

The Url Tracker for Umbraco
MIT License
54 stars 61 forks source link

Who is handling NuGet builds? #143

Closed StephenPAdams closed 8 years ago

StephenPAdams commented 8 years ago

Hey gang,

We're currently up to 3.11 on NuGet. But that's from February 26, 2016. The last commit was on July 2nd. So we're at least 4 months out of date there. There are a number of nice features, particularly @granthughes cache invalidator for slave servers. It'd be nice to get a 3.12 up on NuGet with those features. @kipusoep do you currently have a process for getting UrlTracker up on NuGet that can be shared with the team? Perhaps take some burden off of you?

-Steve

ghost commented 8 years ago

Good point. We need to get on that. @kipusoep what are your thoughts on how releases should be managed now that the time you can spend on this project is so limited? What about an automated approach? I've never used it before, but I have read about projects using AppVeyor for CI and automatic pushes to NuGet. Thoughts?

martinabrahams commented 8 years ago

@granthughes , AppVeyor is great it would take very little to get this project building and publishing to the nuget feed.

I'm sure you guys know but AppVeyor is free for public github projects

StephenPAdams commented 8 years ago

@granthughes and @martinabrahams good idea! Maybe we can do something like make a develop branch? And once pull requests or new features are merged and tested on develop, they can be merged into master. Master can then be hooked to CI on AppVeyor since it'd be free. On successful build, we can trigger a tag to be created and a subsequent deploy to NuGet. We'd just need to ensure that both the NuGet package version and the assembly version are up to date with the build number. Thoughts?

kipusoep commented 8 years ago

Sounds great guys. I have no idea how to tie it all together, releasing a new version is a bit of a pain in the ass at the moment. I guess we could skip the Umbraco package (on our umbraco) from now on, everybody's using NuGet anyways.
If someone need Url Tracker NuGet access, just gimme a shout!

martinabrahams commented 8 years ago

@StephenPAdams sounds like a good idea. For the dev branch, one option is AppVeyor includes a free private nuget feed (known as Account Nuget Feed) with every account, so the dev branch could build and push to the private feed automatically. Anyone wanting to test the latest dev build can install it through Nuget via the private feed (instead of nuget.org)

StephenPAdams commented 8 years ago

@martinabrahams love that idea!

StephenPAdams commented 8 years ago

@kipusoep could you provide NuGet access for myself? @martinabrahams not sure if you're interested as well.

StephenPAdams commented 8 years ago

Looks like @granthughes created a branch called feature/appveyor a few weeks ago. How is this looking, Grant? Any ETA for merging into master and then running it so we can get a new URL Tracker build?

kipusoep commented 8 years ago

@StephenPAdams sure, what's your NuGet username?

StephenPAdams commented 8 years ago

Should be the same as my GitHub name (StephenPAdams). Cheers!

ghost commented 8 years ago

Sorry everyone about my slow work on this lately.

@StephenPAdams, it should be nearly complete. In my branch I got the project to run in Appveyor. Rather than auto-pushing on all commits to master and using a develop branch, as mentioned earlier in this thread, I decided on a different approach that also seems common. My plan is to have it so that all commits to master will trigger a build in Appveyor, but instead of pushing to Nuget, it will push to a new "urltracker-ci" MyGet feed. When a tag is pushed to master, it should then push that commit to Nuget. This gives us more control over when an official release is pushed.

I think the part where I left off was just with connecting Appveyor to Nuget. @kipusoep, can I also have nuget access (username: granthughes)?

Once I have Nuget access, I can start testing the full integration with prerelease packages (so that nobody upgrades to this next version until its confirmed to be working).

Right now my schedule looks clearer than its been lately, so as long as I don’t find too many bugs in the process, I think I can get it operational this week.

StephenPAdams commented 8 years ago

@granthughes that sounds good. I do like the idea of tags controlling the releases to the public NuGet feed. Also dig the urltracker-ci MyGet feed so we can test dev builds.

@kipusoep do you want me to give @granthughes access to the NuGet package? I didn't want to do it without your $0.02.

ghost commented 8 years ago

I've merged in my AppVeyor branch and everything is looking good except for one (hopefully) final thing. My permissions on this repo do not allow me to setup webhooks. This is necessary for AppVeyor to auto-detect pushes. Normally AppVeyor adds this automatically, but my permission level seems to have prevented it. I can trigger builds manually for now, but not for tag commits, so I cannot manually run a build to push the package to NuGet with out current settings. So @kipusoep, we have a few options:

  1. You can temporarily increase my access level for the repo so that I can add the webhook and then reduce my access.
  2. I can give you access to the AppVeyor project and then you can add the webhook. AppVeyor has strange permissions. Once you have an AppVeyor account, I'll need the email address you used, or we could try creating a GitHub team like UrlTracker/AppVeyorAdmins and I can grant access to that team.
  3. You could create your own AppVeyor project to replace mine. It's easy to create a project because all of the settings are in our appveyor.yml. You would just need to change the encrypted keys in it. Since you own the repo, the webhook will be added automatically. You would also want to update the AppVeyor shield/badge in the readme to point to your project.

No matter what, I think you should have access to the repo's AppVeyor project. 2 or 3 from above will handle that. Let me know your MyGet username and I will grant you access to the urltracker-ci feed.

In the meantime, I am going to temporarily remove the restriction of committing a tag for AppVeyor to push to Nuget so that we can get the new package out.

ghost commented 8 years ago

Version 3.12 is now in NuGet. Please post any bugs found as new issues.

I am going to keep this issue open until my previous comment is addressed.

kipusoep commented 8 years ago

Nice job @granthughes! :-)

Re: your question I like option 2, so I created an AppVeyor account called kipusoep or mail@kipusoep.nl.

Let me know when I can set-up the webhook.

ghost commented 8 years ago

@kipusoep I think I have given the right permissions to you for the AppVeyor project.

The webhook URL is on the General settings tab for the project. The content type for the webhook needs to be "application/x-www-form-urlencoded". Only pull requests and pushes need to trigger the webhook. These are the settings that AppVeyor normally sets up on its own.

kipusoep commented 8 years ago

@granthughes I set it up like this, does it look ok?

webhook

ghost commented 8 years ago

@kipusoep Yes, that looks good. I'll revert my temporary removal of the tag limitation for pushing to nuget from the appveyor.yml and push to master later this evening (EST). If the build automatically starts, then everything is good for this.

kipusoep commented 8 years ago

So everything is good @granthughes ?

ghost commented 8 years ago

Yes, everything is glorious