ho-dev
[BUG] Github tag "stable" is referencing an old version
I found a link in "unwritten manual" referencing this tag. Should reference to the same version as "tag_stable".
github release action should set the stable tag too when a new stable version is released.
The tag "stable" still shows to a very old release: https://github.com/ho-dev/HattrickOrganizer/releases/tag/stable
#2090 is another issue concerning out builds.
Do you know if what commit you changed the “development stage” to tag_stable ? I don't see it.
Ah, see it know: https://github.com/ho-dev/HattrickOrganizer/commit/a30d8f1bf5393d6da3fc1fae3debe751566257c8
and the corresponding build: https://github.com/ho-dev/HattrickOrganizer/actions/runs/9636430335/job/26574383286
Yeah, the release is a big mess, with 7.3 artefacts with 8.0: https://github.com/ho-dev/HattrickOrganizer/releases/tag/tag_stable
https://github.com/ho-dev/HattrickOrganizer/releases/tag/8.0
this one is OK
Weirdly the tag is marked has having been created by akasolace, which is odd because the 8.0 release uses the correct PAT it seems.
Still no joy. It works locally (the DEV suffix no longer appears, but it seems it is still there in the latest release). I'll have to spend time on this this evening.
Now the tag 8.0 is also wrong : https://github.com/ho-dev/HattrickOrganizer/releases/tag/8.0 The link from read.me is no longer working.
That bit makes sense at least, since the release ran again, right?
What read.me link are you referring to BTW?
@wsbrenk I am not entirely sure I know/remember the process for a release. Is it possible to make a new release of 8.0?
I think, we should make this possible. Going to a new version without any bug fixes or new features is no good idea in my opinion.
now the list of assets in 8.0 includes DEV and stable items. is the destination of the build process kind of cache? Old builds still existing and we have to clean the directory before building a new release????
It shouldn't: unless something changed, which I am not aware of, it spins up a new container to build every time. I think it merges the assets from the previous tag. I am going to experiment on the test project I have, but it's quite intriguing...
First problem (the persistent -DEV suffix) is caused by the elvis operator on an empty string:
groovy:000> "" ?: "pouet"
===> pouet
Will remove the operator, as the line above sets the index by default.
For the second issue, it seems to be the “Publish Release” task that's pushing way more than expected to the release: https://github.com/ho-dev/HattrickOrganizer/actions/runs/9692579862/job/26746192944
Looking into why now.
For the second issue, it seems to be the “Publish Release” task that's pushing way more than expected to the release: https://github.com/ho-dev/HattrickOrganizer/actions/runs/9692579862/job/26746192944
Looking into why now.
I think this is caused by this line in “Delete previous tag and release” task:
no releases found associated to tag "tag_stable"
The GH task doesn't seem to be able to delete the previous release for that tag.
Really weird behaviour: when deleting the tags manually, all good, but the release looks like pre-release. Then the next one is all weird again, and oddly created by akasolace, which make no sense to me.
It appears that the delete-tag-and-release action does not delete if the release is not a draft:
https://github.com/ClementTsang/delete-tag-and-release/blob/68b0e7be5d0ba50df38996b1763e937dbdc830bb/index.js#L77
So for releases that have the same name (i.e. tag_stable and 8.0), the behaviour we're seeing is somewhat normal, it just merges with the existing content of the release.
Ok, after a loooot of messing, this seems to be addressed, the latest release seems ok. The patched version of delete-tag-and-release is there: https://github.com/tychobrailleur/delete-tag-and-release
I'll propose a PR upstream when I get a chance.
Now the stable is not a release-associated tag, it's just a tag. I presume this is not what you're after, @wsbrenk ? If not I think it'll have to be a third block of delete tag/release, create tag/release, publish.
I'm not really familiar with the GitHub tags and releases either. But it looks like releases/latest is automatically available. No idea why we additionally built a stable and tag_stable. If we would remove both stable tags, we have to change a lot of references in the net using these tags.
I'm currently thinking about what to do with the bug fixes that have been reported to us. Actually, they should lead to at least one version 8.1. To include this in 8.0 would actually be botched. On the other hand, a little botched work isn't so bad - is it?
I think having a version 8.1 is fine. Let's leave 8.0 alone, as it has suffered enough. It would also validate the various release flows.
@tychobrailleur The tag "stable" still does not reference the same as "tag_stable".
@tychobrailleur The tag "stable" still does not reference the same as "tag_stable".
Yes, as indicated above, stable is merely a tag. I haven't been able to figure out yet how to tag a release with two tags. I'll look into the Github docs to see if this is possible.
Just out of curiosity, why do we even need both? If stable is what is used in other places, maybe we should just get rid of tag_stable and update the update logic accordingly?
As I remembered, there is only one tag that's passed to the create release API: https://docs.github.com/en/rest/releases/releases?apiVersion=2022-11-28#create-a-release
I'll try to see if creating the stable tag before creating the tag_stable release also incorporates that tag in the release, but I am not very hopeful here.
@tychobrailleur Akasolace introduced the tag_stable lable at 27.09.2020. So HO versions since V4.0 are using it in their upate url. My favorite would be to change the update url in HO source to "latest" since this is established by github by default, if I understand that correctly. In addition we need a forwarding of "tag_stable" and "stable" urls to this "latest"-url. I don't know, how to creeate such forwardings.
if we don't want to rely on githubs default - we could stay with tag_stable and create only one forwarding url. If it is not possible to create such forwardings, we should stay with tag_stable.
The other option is to create a third release stable (along with tag_stable and short version), but this is getting messy...
My favorite would be to change the update url in HO source to "latest" since this is established by github by default, if I understand that correctly. In addition we need a forwarding of "tag_stable" and "stable" urls to this "latest"-url. I don't know, how to creeate such forwardings.
I don't either: this would be the ideal, forwarding stable to tag_stable...