TO_TAG_DATE blank, and question about passing data
Closed this issue · 31 comments
I noticed that TO_TAG_DATE never returns anything and is blank.
I have it utilized as:
"## What's New\n<sup>Version began on: #{{FROM_TAG_DATE}} - #{{TO_TAG_DATE}}</sup>\n<br />
and I've ensured I satisfied the requirements per the readme:
- name: Build Changelog
id: changelog
uses: mikepenz/release-changelog-builder-action@v4
with:
fromTag: "${{ env.TAG_LAST }}"
toTag: ${{ github.ref }}
configuration: ".github/changelog-configuration.json"
ignorePreReleases: false
commitMode: ${{ inputs.CHANGELOG_MODE_COMMIT }}
fetchReleaseInformation: trueWhich has fetchReleaseInformation enabled. FROM_TAG_DATE returns fine, but TO_TAG_DATE is blank. Unless I'm missing something else I'm not seeing in the docs.
Second question is in regards to the possibility of passing a value.
Right now I have assigned the configuration file as a json.
I have input values at the top of my action
on:
workflow_dispatch:
inputs:
BUILD_ID:
description: "Build ID"
required: true
type: string
default: 00000000-abcd-0123-abcd-000000000000Was wondering if there's a way to pass ${{ BUILD_ID }} from the action script over to the json as a placeholder. Haven't seen anything in the docs specifically for this. Just the ability to use regex to extract info.
The only other way I can think of to solve this, would be to actually hardcore my json template in the action, which gets a bit sloppy.
on the first topic, I will have to look into that in more detail, however this week is quite busy and I may not have time over the weekend. So I can't promise a fast answer on that one.
Related the second question. While there is no built-in feature itself in the action to handle that, there are GitHub Actions specific solutions.
So the one you already describe youself, defining the configuration json as part of the workflow, this is a common practice, and will allow you to use the custom variables right in your workflow.
Alternative would be some shell script which replaces some variables inside your local configuration file, before the action is being executed.
Ultimately if it was part of the placeholders feature -> you would again have to define it in the workflow, as placeholders are configuration.json configurations.
One detail which may be of interset for you in that case:
I suppose you want to define those inputs in the top level template. You can have all your configuration in the configuration.json file on disk, but put the template alone in the workflow configurationJson. So you have your custom template with the custom inputs that way
So if I'm understanding you correct, I can define:
- name: Build Changelog
id: changelog
uses: mikepenz/release-changelog-builder-action@v4
with:
fromTag: "${{ env.TAG_LAST }}"
toTag: ${{ github.ref }}
ignorePreReleases: false
commitMode: ${{ inputs.CHANGELOG_MODE_COMMIT }}
fetchReleaseInformation: true
configuration: ".github/changelog-configuration.json"
configurationJson: |
{
"template": "#{{CHANGELOG}}\n\n<details>\n<summary>Uncategorized</summary>\n\n#{{UNCATEGORIZED}}\n</details>",
}
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
Having most of my config contained in the changelog-configuration.json, but then defining template only in the configurationJson? Then drop my env variable in the template code itself. Need to also figure out the concat structure. With script/v7 it's usually ${{ varname }}
It's late right now, my brain isn't exactly productive.
Exactly. You'd put the ${{ githubActionsVarName }} right there into the template. and you should be good.
Thanks a bunch for this. I had to try about 6 times. I looked over the fact that I left a comma at the end of my json line, which json hates, and it caused it to output a blank changelog.
Once I removed the comma, it seems to work great, and add my custom variable. Only thing I haven't figured out is the end date tag variable. Figured maybe I'm doing something wrong.
Also seems like #{{DAYS_SINCE}} returns blank as well. Yet #{{FROM_TAG_DATE}} is fine. Just weird.
Using Kotlin as my daily language of choice, I dislike that very much too :D. I even looked for that not failing at some point, but the default json handling in javascript doesn't appear to have an option for that
For the end tag, I need to look more into it. But currently very limited on time.
Usually I flip between Typescript, C#, and Lua, which is more forgiving of syntax. Json is one of those languages where if you screw up, it just flat out breaks.
It's fine, I'm in no rush, you've helped out a bunch. It's not vital to my workflow. I just needed the template to work so that I can make my life easier.
Really do appreciate all the help here.
Thank you very much! Will follow up as soon as I had time to look into the last bit
Sure thing, take your time. I may play with it a bit more to see if there's something stupid I'm missing. Like I said, I made sure to enable the required setting.
Ah well, that's for another day.
Thanks again!
Just an update, so you're not going around hunting for a fake bug that doesn't exist.
I actually got it to display. I had the following in my yml config
fromTag: "${{ env.TAG_LAST }}"
toTag: "${{ github.ref }}"I don't remember where I got that from, I believe I was searching for other repos that was running your script. Or maybe from your examples. But I removed that, and on my next test, it returned
Stamp: 1.4.0-2024-03-10T11:39:01.000Z 1.4.3-2024-03-12T13:05:02.000Z 2
I'm not sure why that mattered, but I added the from and to to ensure it would list only the changes for the newest version. Not sure if the script does that out of box.
I took the example you provided in
and used that in my template.Thank you for the update. It seems like this may be a bug, where it does not fetch release information if the tag is provided. Or where it fails to fetch release information for some reason. not sure if you see anything in the action output.
🎉
Oops, sorry. Didn't provide the logs. This is the output when the action was ran when it was breaking:
Run mikepenz/release-changelog-builder-action@v4
📘 Reading input values
ℹ️ Retreived configuration via 'configurationJson'.
ℹ️ Configuration successfully loaded.
ℹ️ Retreived configuration via 'configuration' (via file).
🔖 Resolve tags
ℹ️ Fetching release information was enabled
⚠️ No release information found for refs/heads/main, trying to retrieve tag creation time as fallback.
/usr/bin/git for-each-ref --format="%(creatordate:rfc)" refs/tags/refs/heads/main
⚠️ Could not retrieve tag creation time via git cli 'git for-each-ref --format="%(creatordate:rfc)" "refs/tags/refs/heads/main'
⚠️ No release information found for 1.4.3, trying to retrieve tag creation time as fallback.
/usr/bin/git for-each-ref --format="%(creatordate:rfc)" refs/tags/1.4.3
"Tue, 12 Mar 2024 02:05:02 -0700"
ℹ️ Resolved tag creation time (Tue, 12 Mar 2024 02:05:02 -0700) from 'git for-each-ref --format="%(creatordate:rfc)" "refs/tags/1.4.3
🚀 Load commit history
⚠️ Executing experimental commit mode
ℹ️ Comparing Aetherinox/obsidian-gistr.private - '1.4.3...refs/heads/main'
ℹ️ Found 12 commits from the GitHub API for Aetherinox/obsidian-gistr.private
ℹ️ Retrieved 12 commits for Aetherinox/obsidian-gistr.private
📦 Build changelog
ℹ️ Sorted all pull requests ascending: "ASC"
ℹ️ Remove duplicated pull requests using `duplicate_filter`
PR (0) did not resolve an ID using the `duplicate_filter`
PR (0) did not resolve an ID using the `duplicate_filter`
PR (0) did not resolve an ID using the `duplicate_filter`
PR (0) did not resolve an ID using the `duplicate_filter`
PR (0) did not resolve an ID using the `duplicate_filter`
PR (0) did not resolve an ID using the `duplicate_filter`
PR (0) did not resolve an ID using the `duplicate_filter`
PR (0) did not resolve an ID using the `duplicate_filter`
PR (0) did not resolve an ID using the `duplicate_filter`
PR (0) did not resolve an ID using the `duplicate_filter`
PR (0) did not resolve an ID using the `duplicate_filter`
PR (0) did not resolve an ID using the `duplicate_filter`
ℹ️ Removed 0 pull requests during deduplication
ℹ️ Used 0 transformers to adjust message
✒️ Wrote messages for 12 pull requests
ℹ️ Ordered all pull requests into 12 categories
✒️ Wrote 0 categorized pull requests down
✒️ Wrote 12 non categorized pull requests down
✒️ Wrote 0 ignored pull requests down
ℹ️ Filled template
It appears that "something" went wrong, just not sure what.
Oh, the TO_TAG is refs/heads/main which is not actually a release there is no way for the action to get the release details from this. It will require to be an actual release
As you can see here: https://github.com/mikepenz/release-changelog-builder-action/blob/develop/src/repositories/GithubRepository.ts#L236-L254
it does an API request to get the GitHub Release (not tag) from the API and fetch its information.
As refs/heads/main is also not a tag, it will fail the fallback to get the date via that approach.
Ah ok. You're using octokit, I also use that package for my own library I wrote on typescript / node to deal with gists.
As for what I had inside From and To, are those even needed? I'd imagine by default, your action just fetched the last version anyway.
I'm blind. I just looked through the code real quick and noticed you support Gitea too. Don't know how I missed that in the readme. Got too much crap going on lol
The action tries to be clever on getting from and to. If you want to make sure it picks what you expect you can pass it.
by default: FROM will be either -> the tag if the CI was triggered by a tag, alternative the tag on the hash which was checked out -> otherwise the newest tag found on the repo based on semver
TO will then be resolved relatively as the tag before the FROM based on semver
:D gitea was an awesome contribution from a user of this action.
I'll have to dive later into tags and do some tests.
That was a damn nice contribution from that user. I use Github a lot, but I use Gitea religiously. It's nice having a Git repository that is private and restricted to only me for projects I don't want to share.
OpenGist is also another cool self-hosted solution. I know it supports Git CLI, but I'm not sure about anything else.
Appreciate all the help, and you not telling me to screw off lol. I think I've got the action down pretty well now, plus it's configured how I want now, so I don't imagine too many changes being made until I decide to migrate to v5.
Hey, related to the TO FROM tags.
It seems like since I removed those to/from values, it's now showing commits for previous actions.
I had a series of changes to a program I made (commits, not pull requests), and then it generated the changelog, it didn't show any of those at all. It was showing items that were changed previously.
Yet if I re-add the tag arguments I had from before, it doesn't show the days, or the tag to parameters.
Not sure if I'm doing something wrong, but it's just weird.
Look into the logs, what tags and states does the action identify? (it will tell you from ... to it will make the diff)
I keep forgetting your action has logs.
So I just released v1.4.6 of my plugin, the logs are stating:
📘 Reading input values
🔖 Resolve tags
ℹ️ Found 11 (fetching max: 200) tags from the GitHub API for Aetherinox/obsidian-gistr
🔖 Resolved current tag (1.4.5) from the tags git API
🔖 Resolved previous tag (1.4.4) from the tags git API
ℹ️ Fetching release information was enabled
ℹ️ Retrieved information about the release associated with 1.4.5 from the GitHub API
ℹ️ Retrieved information about the release associated with 1.4.4 from the GitHub API
Where as I want it to just pull everything from the previous release (v1.4.5) to the current release (v1.4.6) (All commits made between the last version and current release).
It seems to be grabbing everything from the two previous tags. Unless I'm missing something.
Going to go back to testing on my other repo and see what happens when I simply specify the fromTag
Let me assume that you don't have the tag nor the release existing yet at the time the changelog is being built.
If you don't provide anything the action will try to find out which release you make. If you don't trigger the build via the tags trigger (which it appears is not the case in your situation) the only other option it has is to get all existing tags from the repo and then go backwards: https://github.com/mikepenz/release-changelog-builder-action/blob/develop/src/repositories/GithubRepository.ts#L206-L234
This now also describes why the TO_TAG_DATE can't be resolved, as there exists none yet. As that tag is not there. So it has nothing to find from the API.
So if you want to run the action before the tag exists, this means you will have to provide the TO_TAG manually as you did before. If you do so no TO_TAG_DATE can be resolved as the action can't load release information for a release which does not yet exist. So you will have to set this manually.
I wonder if a small optimisation could be that if the TO_TAG is provided, and it can't find any information from the API, nor the tag doesn't appear to exist, that it assumes the release TO_TAG_DATE is now() however that might not be true for all cases. 🤔
Oh, so the primary issue is that if does not yet even know that the new tag is to be released, so it's skipping back between 1.44 and 1.45
So I'm assume somewhere in the action, I'd have to create the tag prior to doing anything related to a changelog.
That's another thing I'm going to have to look up. Because it is works better having the tag created first, then I'd rather do that.
I'm going to assume that
softprops/action-gh-release@v2
name: v${{ env.PACKAGE_VERSION }}
tag_name: ${{ env.PACKAGE_VERSION }}Is where my tag is created. So now I've got to figure out how to break that up.
Personally I usually have my release workflow triggered by pushing a tag. And have the automation then make the release on GitHub build the changelog and do all the associated tasks.
I know that in some cases people want to update a CHANGELOG.md file, in which case that won't work as you want it updated before the tag. For these scenarios you need to provide the TO_TAG manually to the action, because how else would it know the new tag :D. this information has to come from somewhere
See in this action here I trigger my build when a tag is pushed:
Not sure what your trigger right now is.
And then if it was a tag, do the release steps: https://github.com/mikepenz/release-changelog-builder-action/blob/develop/.github/workflows/ci.yml#L168-L190
To be honest, my workflow for this is rather complicated at the moment: https://github.com/Aetherinox/obsidian-gistr.private/blob/main/.github/workflows/release-tag.yml
Because I have it doing many things, so it has made it confusing to figure out what is coming from what.
So you're saying the other option is to simply provide a TO_TAG without a from? that just specifying the tag name for the release currently being generated?
Interesting. Looks like the tag is crated here before: https://github.com/Aetherinox/obsidian-gistr.private/blob/main/.github/workflows/release-tag.yml#L158
But the GitHub APi does not appear to return it then yet: https://github.com/mikepenz/release-changelog-builder-action/blob/develop/src/repositories/GithubRepository.ts#L208C40-L208C48
So weither the tag step doesn't work, or GitHub APi is a bit slow 🤔
Oh, could it be 💡 : https://github.com/Aetherinox/obsidian-gistr.private/blob/main/.github/workflows/release-tag.yml#L158 doesn't push the tag to the remote?
But yes, if you only provide TO_TAG the action should be able to resolve things itself.
Which just will leave the problem of TO_TAG_DATE not being filled, given the release doesn't yet exist, but that is something I need to think about if it makes sense to fill it in that case just with the current timestamp.
Oh, sorry. I literally just added that code. It wasn't there before.
I'm running tests now to see if it actually works.
If this new script to create the tag works, does that mean I still need to append TO_TAG to your action? Or should it be able to pick up on that automatically?
I cannot confirm yet because I know how crap just decides to break when I get my hopes up. But it does appear to be creating the tag prior to your action.
And then your action shows
🔖 Resolve tags
ℹ️ Found 15 (fetching max: 200) tags from the GitHub API for Aetherinox/obsidian-gistr.private
🔖 Resolved current tag (1.4.6) from the tags git API
🔖 Resolved previous tag (1.4.4) from the tags git API
ℹ️ Fetching release information was enabled
⚠️ No release information found for 1.4.6, trying to retrieve tag creation time as fallback.
Which would be correct (I skipped v1.4.5 on that repo).
Not sure what the "No release information" means though.
ah :D that explains a lot.
Yes that should work in that case, and no TO_TAG needed.
No release information found for just means that no GitHub release was found (which is correct, there is none) however it using the TAG Creation time which is what you want. :).
So this should what you expect
Really sorry for all the issues lol. Normally with other languages and projects, I'm quick to pick things up. Github actions are still new as heck to me, so I'm getting the feel for it.
I promise to leave you alone lol. Everything else works perfect with the script, just that one issue I couldn't figure out. But it makes sense now, I wasn't even thinking about the fact that no tag existed, so it had no clue that it should create the new tag first.
Kept confusing me why it was always a release behind. Hopefully these tests work and I can be done with this lol
Edit: I just threw a test up. It worked beautifully:
ℹ️ Found 16 (fetching max: 200) tags from the GitHub API for Aetherinox/obsidian-gistr.private
🔖 Resolved current tag (1.4.7) from the tags git API
🔖 Resolved previous tag (1.4.6) from the tags git API
ℹ️ Fetching release information was enabled
⚠️ No release information found for 1.4.7, trying to retrieve tag creation time as fallback.
https://github.com/Aetherinox/obsidian-gistr.private/releases/tag/1.4.7
No worries.
There are a lot of different systems playing together :).
YaY 🎉 That's awesome :)
Really friggen appreciate the help again. Seriously. you have no idea how great you've been. Hopefully this is it. Everything else seems to work perfect.
Now I just need to take that workflow, back it up, and stick it in a lock box so I never lose it lol
Really appreciated! Right in time for the weekend :D
Haha :D. You have documented it well, and formatted it nicely. so Git will do the rest for you :)
I believe we can close it with some 🥳
Sure thing. Have a good weekend. I promise, I won't bug ya lol
Thanks again.