release artifacts for v0.0.24 are missing

[malt3]

It looks like something went wrong here: https://github.com/uutils/coreutils/actions/runs/7596318857

EDIT: I'm seeing this error between a mountain of weird output:

2024-01-20T19:21:23.9087255Z [0m          C:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/12.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:\Users\runneradmin\.cargo\registry\src\index.crates.io-6f17d22bba15001f\windows_x86_64_gnu-0.42.2\lib/libwindows.a(ntdll_dll_s00082.o): illegal symbol index -1869611008 in relocs

Pipeline is green now but release artifacts are still missing.

[tertsdiepraam]

See also: https://github.com/uutils/coreutils/discussions/5915

@cakebaker seems to just have triggered a rerun of the actions. Hopefully that'll fix it.

[malt3]

I found something: the variable steps.vars.outputs.DEPLOY was not set to true. This is why the release with artifacts was never triggered: https://github.com/uutils/coreutils/actions/runs/7596318857/job/21112947690#step:6:135

This is the case since the CICD workflow was never triggered on the release tag.

I think I found the root cause: since https://github.com/uutils/coreutils/commit/4d2bdf497ab030871a7a84191010637a355ffd7e, workflows are only triggered on commit pushes to main (not tags).

[malt3]

Do you think it is possible to either fix the release artifacts for v0.0.24 manually or do a new release soon?

[tertsdiepraam]

We're about halfway until the next release, so I don't see a particular rush to fix this at the moment. Do you really need them in addition to all the other installation methods?

[malt3]

With #5694 (which is in 0.0.24), I was trying to get a larger set of statically linked release artifacts. I need this for another PR in another repo which depends on those binary artifacts: https://github.com/aspect-build/bazel-lib/pull/706

But I also totally understand if you prefer to just wait until the next release.

[loeffel-io]

v0.0.25 and the artifacts are still missing i need this for github.com/loeffel-io/ls-lint

[sylvestre]

yeah, dunno why :( help welcome!

[malt3]

This time it was an issue with the cargo.lock file, as can be seen here: https://github.com/uutils/coreutils/actions/runs/8404507913

I think this issue was resolved with the next commit on main: https://github.com/uutils/coreutils/commit/68c77b4bd129bdc12d03cc74fe0f817d2df75894

[sylvestre]

I have been trying to do a 0.0.26 for artifact but some Windows systems have been failing. I am waiting for them to be fixed upstream (github)

[QuentiumYT]

Is it possible to attach the binaries to the previous 0.0.24 and 0.0.25 releases? Would be useful for not searching through CICD random commit builds :)

[tertsdiepraam]

I'd rather focus on fixing it. Artifacts generated by GH actions are always better than something uploaded manually so you at least get a bit of assurance that it's correct (especially considering the recent news around security issues in release tarballs :) )

[QuentiumYT]

I agree, but once the build action is fixed, these 2 releases will not be updated automatically right? I was thinking about publishing the actions artifacts anyway :) Better for security indeed!

[sylvestre]

They probably won't be regenerated. We start try to restart the tasks but not idea if it will work or not

[tertsdiepraam]

I took a step to hopefully fix this: https://github.com/uutils/coreutils/pull/6181

I'm of the opinion that we shouldn't generate artifacts for the old releases. uutils is too unstable to be concerned with that in my opinion. We'll experiment with fixing this with pre-releases for 0.0.26 instead of making a real release right away, so that we won't have more proper releases without artifacts. Once it works, we release 0.0.26 and everybody can be happy again.

[rivy]

I believe that https://github.com/uutils/coreutils/pull/6270 will fix the issue. It's working correctly on a test clone.

Ping me when the next release is on deck and I'll be happy to help debug any issues.