search

mikepenz / release-changelog-builder-action

A GitHub action that builds your release notes / changelog fast, easy and exactly the way you want.
https://blog.mikepenz.dev
Apache License 2.0
721 stars 103 forks source link

Output of all categorized entries? #1113

Closed kvernon closed 1 year ago

kvernon commented 1 year ago

Howdy again @mikepenz ,

I have a new question for you,

Does this changelog build action output the categorized entries?

My goal is to take that data and use it to better version the code-base and a lot of what is in here could lead to that. Looking at the docs I see output counts, but not the grouped entries.

Thanks, Kelly

mikepenz commented 1 year ago

Good day.

It depends on what exactly you mean with that. The general categorised entries and thus results in form of the changelog (as String), yes.

The categorized entries in form of a list -> no, given we don't really have a good way to pass over more complex data structures to other actions.

Maybe you can explain in a bit more detail what data in which form you look for?

Also Thank you very much for the sponsor

kvernon commented 1 year ago

Totes Mike!

So today, when the changelog builds up how to organize the information, we get features, bug fixes, major, tests, etc...

A while back, you helped me with organizing through the branch prefix.

It would be amazing if there was a way to output those organized findings as a collection for us to iterate against.

Like... Let's say I get:

[
 "feat",
 "feat",
 "fix"
]

This would show a collection of each grouped merged / change discovered from one version to the next. It doesn't need to show the actual title of the pr, it would show each group entry.

I could pass this along, and translate it to count up to the next sem version. Also, I'm considering a simple scenario here to use with actions knowing how complicated it can be to pass and transform from shared actions internally.

Equally, another option could be to return a more complex, and meaningful, array that spits each entry back with the group info.

[{
   group: "feat", comment: "this code solves my hunger issues" }, {
   group: "feat", comment: "added corn to app" }, {
   group: "fix", comment: "resolved tomatoes growing without sun"
}]

Cheers, Kelly

On Fri, May 19, 2023, 6:41 AM Mike Penz @.***> wrote:

Good day.

It depends on what exactly you mean with that. The general categorised entries and thus results in form of the changelog (as String), yes.

The categorized entries in form of a list -> no, given we don't really have a good way to pass over more complex data structures to other actions.

Maybe you can explain in a bit more detail what data in which form you look for?

Also Thank you very much for the sponsor

— Reply to this email directly, view it on GitHub https://github.com/mikepenz/release-changelog-builder-action/issues/1113#issuecomment-1554447822, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABIFSGFMAAA2GVITKPBHU5DXG5MAJANCNFSM6AAAAAAYHTTVL4 . You are receiving this because you authored the thread.Message ID: @.*** com>

mikepenz commented 1 year ago

@kvernon given we can only put non complex data in the output, I actually looked up what's the maximum size for the output. Looks we got 50MB total, with 1MB max per output entry.

Which seems more than enough to actually output a complex json. Which in return should be pretty easy to consume by any other tool afterwards.

kvernon commented 1 year ago

@mikepenz ,

I missed your last comment. I'm sorry it took a while on the sponsorship. You're very helpful with me and others. I just wanted to show how appreciative I was with your help. Thank you for everything!

For this other part (this thread)... If that's something that's doable -- awesome sauce! I'll be keeping a watch! Equally if we need to hash out the scope to make this more broad, I'm good with that too. 😃

Cheers, Kelly

mikepenz commented 1 year ago

Well if you could try out: https://github.com/mikepenz/release-changelog-builder-action/pull/1115 that would help a lot :)

You can include it via the commit hash

 uses: mikepenz/release-changelog-builder-action@be9b53104ea685d17180d2cf0912b8351fafa87f
kvernon commented 1 year ago

Oh wow!! You're incredible sir!

Now, here's the (kinda downfall). I don't have an ability to test this today. I took a much needed break today from work. Is it OK if I try it out Monday when I get back?

kvernon commented 1 year ago

Looking at the change:


  // serialize and provide the categorized content as json
  const transformedCategorized = Array.from(categorized).reduce((obj, [key, value]) => Object.assign(obj, {[key.title]: value}), {})
  core.setOutput('categorized', JSON.stringify(transformedCategorized))
  1. what's the shape?
  2. Seeing this go out as a string, does it become a json string on final out, or is it already json?
mikepenz commented 1 year ago

It's a string, but in the format of a JSON. so you should be able to use javascripts JSON.parse(json) to get an object from it again afterwards.

The shape would be a json object with the title of each category as key, and then an array of the PRs.

and yes, please test whenever you have time :). No stress

kvernon commented 1 year ago

I'm taking a look now ... BTW

kvernon commented 1 year ago

GM @mikepenz !

I like the update you did - thank you!

Taking a look at it, I see the following from a test run:

changelog: "## 🐛 Fixes - bugfix: updated to expand version with only major. Minor - PR: #42 "

new categorized: {"## 🚀 Features":[],"## 🐛 Fixes":["- bugfix: updated to expand version with only major. Minor\n - PR: #42"],"## 🧪 Tests":[],"## ???? Unknown":[]}

It looks like this is based upon the formatting from the changelog.json file of title, do you think there could be an alias for the changelog.json where I can have the nice title, but have some kind of easy grouping?

kvernon commented 1 year ago

@mikepenz

One thing I'm realizing as I walk through this too, is (thoughts moment here BTW), for the above to be successful, Is there a way to have it aggregate based on non-existing starting tag ~ sha?

Where this is going is that I'd love to auto-generate a version number based on what your system sorts. Currently in the examples, tags seem to need to be existing -- from - to. In the case with our stuff, we don't do a commitlint strategy, we're using the branch prefix (feature/hotfix/bugfix, etc...) to determine how to increase the release version. This might be a different GH issue for here too...

In our system today, we do tag our stuff, but not knowing the tag version (and wanting to use this) creates a system paradox! :) or chicken or the egg scenario. For GH actions, it does supply the sha today. Either way, please let me know your thoughts on this.

mikepenz commented 1 year ago

@kvernon you can replace the tag (on both sides (from / to)) with any git ref, and it will work as if you did provide a tag. 🎉

ccremer commented 1 year ago

Just chiming in here :) @kvernon your use cases sounds very much like what I have outlined in #902 . Having the categorized PRs in the action's output is crucial for any subsequent follow-up logic regarding releasing.

@mikepenz I would very much welcome this feature that you have started as part of this issue :)

mikepenz commented 1 year ago

@ccremer what would be missing from this effort to resolve #902?

kvernon commented 1 year ago

@mikepenz ,

For me, I'm slow on this one, and I'm sorry. It's been am exhausting week here. I've been trying to set up tests around this idea when I can with the small bits of time I've had.

mikepenz commented 1 year ago

@kvernon no worries. Don't stress yourself.

ccremer commented 1 year ago

what would be missing from this effort to resolve https://github.com/mikepenz/release-changelog-builder-action/issues/902?

Actually, just this change you already made in #1115 at the bare minimum :)

In #902 we discussed that decision making of a SemVer and also releasing is out of scope of this action. Which is fair enough since this action is version-scheme agnostic AFAIK, so it doesn't "know" SemVer resp. what each category means regarding a possible release workflow.

However, with the categorized PRs as JSON in the action's output I'll be able to write an additional action that gives the SemVer meaning to the categories. As an example, this new action could just print out "minor" in its output if there is at least 1 PR in the "features" group in the categorized output JSON, or "none" if there were only documentation changes that don't trigger a new release of something.

If you think it's not worth to have a dedicated action that outputs "major", "minor", "patch" or "none" resp. it's useful to have it in this action, then by all means, let's do that. Now that I've picked up TS programming, I might even contribute a PR for this. But I would also be happy to maintain a separate action that uses the JSON output alone :) But before I start hitting the keyboard, I wanted to know your thoughts on this matter.

kvernon commented 1 year ago

@ccremer ,

My goal is similar, but in a high level approach the idea is to include in the changelog.json (config file) a semVer property in each grouped where I write what these equate to for the new version increment.

So...

categories: [{
    title: '### my bugfixes',
    semVer: 'patch'
}]

Then later on I apply them to the generate a new semantic version.

mikepenz commented 1 year ago

Thank you both for the feedback.

@kvernon with the latest change (and merged into the dev branch) there is now also the ability to provide a key to the category which is used for the json output, instead of the title.

@ccremer I actually believe that I will have a plan for this action, which would much better provide capability and compatibility with your suggestion. However I need to do a bit more research on it before I commit to it. However if things turn out to work as I believe, a separate action would still work, kind of as a "plugin".

ccremer commented 1 year ago

My goal is similar, but in a high level approach the idea is to include in the changelog.json (config file) a semVer property in each grouped where I write what these equate to for the new version increment.

I had exactly the same idea in mind, to have the increment configurable per category :)

@mikepenz sounds good!

mikepenz commented 1 year ago

@ccremer ok. Found some time to explore what I wanted to try. (not yet sure if the env variable approach is going to stay, or if I want to move it into an output var) Regardless:

https://github.com/mikepenz/release-changelog-builder-action/pull/1123/files#diff-b803fcb7f17ed9235f1e5cb1fcd2f5d3b2838429d4368ae4c57ce4436577f03fR115-R153

This PR offers now that you can run the action once - however only have it collect the PRs. Then re-run it afterwards taking the previous data as input, and only generating.

What that practically means now.

You can do:

what that also means ->

ccremer commented 1 year ago

@mikepenz That sounds reasonable.

kvernon commented 1 year ago

Good Morning @mikepenz ,

This is looking great so far -- thank you again sir! How difficult is it to add the date to the categorized entries? If it's crazy hard, don't worry...

mikepenz commented 1 year ago

@kvernon at the point of time when we write it to the exported json, we sadly don't have the available at this time. As those PRs are already transformed into the format as requested by the config

However. Given the latest changes, you can have 2/3 different steps, one which fetches all the data, then one with template which has the date in the PR template for your usecase, and one for the visualisation

mikepenz commented 1 year ago

The new features will probably end up in a v4. Which is still pending some further exploration.

However the latest commit on develop right now, contains all changes for this issue

kvernon commented 1 year ago

I went back to look at the config, and it looks like I can add ${{MERGED_AT}}, so I'm happy about that. Thanks for calling that out @mikepenz !

From the overall world of this tool, it sounds like a lot has changed, and I'm trying to understand it better. Specifically:

you can have 2/3 different steps

Is there a thread where I can learn more about this idea?

mikepenz commented 1 year ago

@kvernon not a thread, however there is the sample action in this actions testcases which showcases it: https://github.com/mikepenz/release-changelog-builder-action/pull/1123/files#diff-b803fcb7f17ed9235f1e5cb1fcd2f5d3b2838429d4368ae4c57ce4436577f03fR115-R153

More documentation and possibly examples to come in the future. that's the core functionality for now though

mikepenz commented 1 year ago

I believe with https://github.com/mikepenz/release-changelog-builder-action/pull/1132 landing soon, we can close this as complete?

mikepenz commented 1 year ago

Available in v4 (v4.0.0-b01)