rpm_action.yml: Run all but release creation every time

[hartwork]

Related to #488

This will make problems in all but the last step show earlier, and hence help with debugging and keeping the workflow healthy. The existing if: startsWith(github.ref, 'refs/tags/v') already guards release creation for non-tag and non-v-tag pushes.

CC @henry2cox

[hartwork]

@henry2cox update: now rebased onto latest master to resolve conflicts after merge of #489.

[henry2cox]

Question: do you also think I should be able to just re-tag with v2.5 - and the release will be rebuilt, with all the expected content? Or delete the current release and tag and create new release?

[hartwork]

Question: do you also think I should be able to just re-tag with v2.5 - and the release will be rebuilt, with all the expected content? Or delete the current release and tag and create new release?

@henry2cox I have seen tag moves and re-releases bite downstreams in the past, so I would personally recommend against re-creating the Git tag and/or re-placing the artifacts under the same name for existing tag v2.5. I think personally I would:

• Keep the old 2.5 release but…
  • Drop the "Release " prefix
  • Delete the two beta-named RPM artifacts (which results in a fine release, just without artifacts)
• Bump versions to "2.5.1" everywhere in master (potentially via a pull request)
• Push a new tag v2.5.1 and let the CI do the release creation

What do you think?

[henry2cox]

looks like I can just change the name of the asset.
Still doesn't contain the tarball - but perhaps that doesn't matter so much.

[hartwork]

looks like I can just change the name of the asset.

@henry2cox did the "beta" go into the RPM artifact content? Then the rename alone could be trouble 🤔

[henry2cox]

Yeah..I think I broke it.
In view of the very low number of downloads so far - I think, just you :-)
I'm going to cheat and just delete the current version and try again.

[hartwork]

@henry2cox I see a new release now at https://github.com/linux-test-project/lcov/releases/tag/v2.5 but with no artifacts (yet?) and a markdown syntax issue near "support llvm/22".

[henry2cox]

Yes...I think 'yet' - seems to take a couple of minutes to build.
and yeah - typo (fixed) Never try to do 3 unrelated things across 2 computes, simultaneously.

[henry2cox]

hmm. Or maybe not. Has been a few minutes - but no artifacts have appeared, yet.

[hartwork]

@henry2cox I'm having trouble finding the related CI run for a Git tag at https://github.com/linux-test-project/lcov/actions . Is the current 2.5 release a result of CI?

[henry2cox]

Yes.

[hartwork]

@henry2cox I only see https://github.com/linux-test-project/lcov/actions/runs/28754646970 of yesterday. How did you you re-run the CI for 2.5? I'm also wondering if re-running CI for 2.5 can produce anything but the previous incomplete results if the tag also controls the workflow files being checked out. Maybe we need a new v2.5.1 tag in any case.

[hartwork]

@henry2cox is there a chance for adding a source tarball manually to 2.5 or to let CI create 2.5.1 with a source tarball? It would allow me to bump lcov in Gentoo and to potentially signal other distros to follow via the RSS feeds tied to https://repology.org/project/lcov/history . What do you think?

[henry2cox]

Nothing I tried so far has quite worked.
So next thing is to try to delete the release and the tag..and try again.
Updating the release after making a few changes - did not have the desired effect.

If that doesn't work, then I'll try a 2.5.1 hack.