search

CarterCommunity / Carter

Carter is framework that is a thin layer of extension methods and functionality over ASP.NET Core allowing code to be more explicit and most importantly more enjoyable.
MIT License
2.05k stars 172 forks source link

[WIP] New build tool #299

Closed mderriey closed 1 year ago

mderriey commented 1 year ago

Fixes #298

This is my first attempt at trying to come up with something that fits the bill. Mostly to get something in front of you and get feedback.

For now, I've created different workflows to make it easier for me to test things; in the future, we could look at consolidating them and including some logic within the workflow itself. They're mostly the same, the things that change are:

Here's the list of actions I took on the repo, and what would happen:

Action taken Result Link to workflow
Opened a PR Carter prerelease package pushed to feedz https://github.com/mderriey/Carter/actions/runs/3113410773/jobs/5048006852#step:6:1
Merged a PR Carter prerelease package pushed to NuGet https://github.com/mderriey/Carter/actions/runs/3113457288/jobs/5048111598#step:6:1
Created the 6.1.3 tag Carter release package pushed to NuGet https://github.com/mderriey/Carter/actions/runs/3113464170/jobs/5048127102#step:6:1
Carted the newtonsoft-6.0.0 tag Newtonsoft release package pushed to NuGet https://github.com/mderriey/Carter/actions/runs/3113483201/jobs/5048168976#step:6:1
mderriey commented 1 year ago

@jchannon would you mind taking a look and letting me know if that sort of fits what you had in mind?

Very keen for feedback and happy to make changes to adjust things.

Cheers.

jchannon commented 1 year ago

Looks good, the only thing I wouldnt want is a push to nuget on a PR merge. For pre-releases I'd probably tag the repo as 7.0.0-beta1 for example

mderriey commented 1 year ago

Looks good, the only thing I wouldnt want is a push to nuget on a PR merge. For pre-releases I'd probably tag the repo as 7.0.0-beta1 for example

OK, got it, I'll push an update for this.

jchannon commented 1 year ago

No you were right, I just couldn't envisage how we'd do two separate tag approaches :)

I am wondering if I move it out into it's own repo whether that might be clearer however I'd still somehow want to bump those external packages to use the latest carter when we release a new carter version

On Mon, 26 Sept 2022 at 12:59, Mickaël Derriey @.***> wrote:

@.**** commented on this pull request.

In .github/workflows/publish-release.yml https://github.com/CarterCommunity/Carter/pull/299#discussion_r979920266 :

@@ -0,0 +1,29 @@ +name: Main tag created workflow + +on:

  • push:
  • tags-ignore:
    • 'newtonsoft-*'

I used different tags as I thought you wanted to be able to have different versions of the Carter and the Carter.ResponseNegotiators.Newtonsoft packages while the source stays in the same repo.

"Regular" tags, like v7.0.0, would release Carter, while newtonsoft-v7.0.0, would release the Carter.ResponseNegotiators.Newtonsoft package.

Did I make a wrong assumption thinking you might want to keep their versioning separate? My thinking was that if we keep them in sync, new versions of Carter.ResponseNegotiators.Newtonsoft could be released without any changes in them.

— Reply to this email directly, view it on GitHub https://github.com/CarterCommunity/Carter/pull/299#discussion_r979920266, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAZVJTADOJPVEIW4KOUKCDWAGFZNANCNFSM6AAAAAAQUBPU6Q . You are receiving this because you were mentioned.Message ID: @.***>

mderriey commented 1 year ago

No you were right, I just couldn't envisage how we'd do two separate tag approaches :)

Cool 👍

I am wondering if I move it out into its own repo whether that might be clearer however I'd still somehow want to bump those external packages to use the latest carter when we release a new carter version.

I think there are several options here:

  1. In the same workflow as the one where we release the Carter package, we can find/replace references to the Carter with the latest version; this works for things that are in the same repository.
  2. We could also imagine a separate workflow that queries NuGet for the latest Carter version, update package references, then run some kind of tests; this could work for things in the same repo and in different repositories.

Whether to move it in its own repository is up to you, I'd say. If you don't foresee many other projects with a different release cycle, keeping it in here doesn't add too much "engineering" overhead in my opinion. If/when we hit issues, we can always move it. Maybe some folks at NDC will have opinions based on how painful it was for them 😉

For the template project, one thing I did in the past that worked fairly well was the following:

This way, you always keep an updated template project with the latest Carter version.

jchannon commented 1 year ago

I mean we already have a couple of external repos that depend on carter as a package reference but have not been kept up to date really because of the complexities here and me being bothered to work out to do it best :) So if we did move the newtonsoft package out then we'd have 3 or 4 repos that need the package refence updated. Whilst you say we could query nuget, how would you do that, a timer or I wonder if there is a cross repo trigger eg/Carter gets tagged and can then somehow notify other repos.

Regarding the template I also came up with that idea but never got around to doing it, if we did swap the references I'd also want to do that automatically as I already manually change it once Carter is released and I don't like that :)

mderriey commented 1 year ago

Whilst you say we could query nuget, how would you do that, a timer or I wonder if there is a cross repo trigger eg/Carter gets tagged and can then somehow notify other repos.

I'm not aware of cross-repo way of triggering workflows.

My initial idea was manually triggering the workflow run (I didn't know there were other repos with package references to Carter), but scheduled runs could also work.

Regarding the template I also came up with that idea but never got around to doing it, if we did swap the references I'd also want to do that automatically as I already manually change it once Carter is released and I don't like that :)

I wasn't clear enough, apologies. Yes, the swapping was done automatically when I implemented that at work a while ago.

jchannon commented 1 year ago

A manually triggered workflow that did a find and replace, commit and asked for a tag and then pushed and released to nuget could be very handy indeed!

mderriey commented 1 year ago

OK, we can have a look at that in the future.

How would you like to go forward with this PR? Do you want to wait for .NET 7 to be out and your changes to be merged to main, or should we try and get something merged soon-ish and adapt when the split-out Newtonsoft project gets merged to main?

mderriey commented 1 year ago

@jchannon friendly bump about https://github.com/CarterCommunity/Carter/pull/299#issuecomment-1259588253

jchannon commented 1 year ago

👍 will take a look next week. At NDC at the mo 😁

On Fri, 30 Sep 2022 at 10:54, Mickaël Derriey @.***> wrote:

@jchannon https://github.com/jchannon friendly bump about #299 (comment) https://github.com/CarterCommunity/Carter/pull/299#issuecomment-1259588253

— Reply to this email directly, view it on GitHub https://github.com/CarterCommunity/Carter/pull/299#issuecomment-1263299576, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAZVJWPMCONT7MOVFR3XITWA2TEXANCNFSM6AAAAAAQUBPU6Q . You are receiving this because you were mentioned.Message ID: @.***>

jchannon commented 1 year ago

As your PR is going to be merged into my branch which has all the .NET 7 changes on it I wonder if we can get it all working in your branch? I just approved a thing in GH Actions so any changes made in the workflow files should build here 🤞

mderriey commented 1 year ago

I've made a few changes to test out the real thing, but I believe it will need to be tested on your repo as I'm fairly certain I won't have access to your repo's secrets, like the feedz.io API key.

mderriey commented 1 year ago

It now says that the workflow is awaiting approval, so I suppose you need to do something on your end.

To test the whole thing, you'll need to add:

The scenarios to test those would be:

It's a bit awkward testing this as it will push packages to NuGet; can you unlist them afterwards? Or maybe you could create tags with versions lower than the current one so that consumers don't get asked to update?

You also mentioned earlier that you would create tags with a leading v, like v7.0.0; if you still want to go this way, I'll need to make a slight change to let MinVer know that the tags contain a prefix.

jchannon commented 1 year ago

Ok, approved the workflow.

Tags don't seem to contain the prefix on the repo, I just checked.

mderriey commented 1 year ago

Ok, approved the workflow.

Sweet, thanks.

The run failed, supposedly because the workflow didn't have access to the FEEDZ_KEY secret, see https://github.com/CarterCommunity/Carter/actions/runs/3174168115/jobs/5201477628#step:6:8.

Maybe you need to enable forks having access to the secrets? It's a bit sketchy, unless you can do this on a case-by-case basis. Otherwise, we could look at making me a temporary contributor to this repo and I open a PR from a separate branch in this repo?

Tags don't seem to contain the prefix on the repo, I just checked.

OK, so you want to keep it this way, with no prefix?

jchannon commented 1 year ago

Just given you write access! 😄 See if that helps, if not I can bump the access.

Yeah no prefix required

mderriey commented 1 year ago

Just given you write access! 😄

Sweet, thanks, opened #300 and closing this PR.