feat: better ci

[Sped0n]

• 285

• add linux armv7 and macos arm64 to build target

this is what it looks like:

• release: https://github.com/Sped0n/macchina/releases/tag/v0.1.1
• CI: https://github.com/Sped0n/macchina/actions/runs/5488290817

[Sped0n]

Also, should we wrap the artifacts with tar? Since upload-artifacts will not retain artifact permissions, I have to admit, being forced to run chmod manually is kinda annoying and not friendly to some new users.

The main concern about this modification is that some package managers might just download the artifact directly, and replacing them with compressed tar package may disrupt their installation.

[grtcdr]

Hey,

Thanks for these additions.

Also, should we wrap the artifacts with tar? Since https://github.com/actions/upload-artifact/issues/38, I have to admit, being forced to run chmod manually is kinda annoying and not friendly to some new users.

I agree that it may a little annoying to have to do that manually, but --

The main concern about this modification is that some package managers might just download the artifact directly, and replacing them with compressed tar package may disrupt their installation.

I'd like to ask @0323pin (pkgsrc package maintainer) if he minds. Whether this would cause any futher troubles with other package managers, I don't know.

Actually now that I remember, pkgsrc builds from source, so this won't affect their build process.

I highly doubt if any package manager is just re-packaging the release artifacts, that sort of defies the purpose of any transparent process.

But, there's an AUR package, which neither I nor the co-authors maintain, that offers the same releases for Arch users. They'll need to make changes to their PKGBUILD if we are to proceed with this proposed change.

[Gobidev]

Also, should we wrap the artifacts with tar? Since https://github.com/actions/upload-artifact/issues/38, I have to admit, being forced to run chmod manually is kinda annoying and not friendly to some new users.

For pfetch-rs, I compress all binaries except the .exe for Windows, since .tar.gz is not natively supported there and the extra permission is not needed. The workflow looks like this: https://github.com/Gobidev/pfetch-rs/blob/d3a1d12c346e99e398456bd6344cffb52cfe3e1b/.github/workflows/release.yml#L149

[0323pin]

Actually now that I remember, pkgsrc builds from source, so this won't affect their build process.

Yes, that's correct. But, we do use cargo/rustc to build it. I can try a build when this is implemented and test but, we pull from the source code and use nothing from the GitHub CI.

[Sped0n]

For pfetch-rs, I compress all binaries except the .exe for Windows, since .tar.gz is not natively supported there and the extra permission is not needed. The workflow looks like this: https://github.com/Gobidev/pfetch-rs/blob/d3a1d12c346e99e398456bd6344cffb52cfe3e1b/.github/workflows/release.yml#L149

thx, actually I have already finish the code, just not sure whether to push it or not.

[Sped0n]

got the wrap up jobs done, ready to merge

btw I add more targets to ci, just want to help out those who don't want to mess around with the build

test result

ci: https://github.com/Sped0n/macchina/actions/runs/5495602692 release: https://github.com/Sped0n/macchina/releases/tag/v0.1.2

[Sped0n]

@Gobidev maybe be a liitle bit off topic, but do you want this version naming artifacts feature comes to petch-rs? If you do I can make a pr later or you can just copy my code here

[Gobidev]

@Gobidev maybe be a liitle bit off topic, but do you want this version naming artifacts feature comes to petch-rs? If you do I can make a pr later or you can just copy my code here

@Sped0n thank you for the offer, but I don't really see the reason to change it right now. The problem described in #285 does not apply to the pfetch-rs-bin AUR package since the PKGBUILD saves the downloaded archive under a version specific name. The other packages (nix, brew) build from source.