Output of all categorized entries?
kvernon opened this issue · 29 comments
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
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 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.
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
Well if you could try out: #1115 that would help a lot :)
You can include it via the commit hash
uses: mikepenz/release-changelog-builder-action@be9b53104ea685d17180d2cf0912b8351fafa87f
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?
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))- what's the shape?
- Seeing this go out as a string, does it become a json string on final out, or is it already json?
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
I'm taking a look now ... BTW
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?
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.
@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.
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 :)
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.
what would be missing from this effort to resolve #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.
@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.
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".
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!
@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:
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:
- run once -> collect PRs
- run it then with a special config so you can identify if major, minor, patch (you can use your action to do that)
- run it again with the
toTagspecified now, or with whatever template you need, and have it generate the real changelog
what that also means ->
- you can now much "cheaper" generate multiple release notes in different formats without pulling all data over and over again.
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...
@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
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
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?
@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
Available in v4 (v4.0.0-b01)