search

eza-community / eza

A modern, maintained replacement for ls
https://eza.rocks
MIT License
8.76k stars 171 forks source link

bug: `cross` release step stalls for unknown reasons since 0.18.17 #1023

Closed rehanone closed 2 weeks ago

rehanone commented 2 weeks ago

The release v0.18.18 has not binary artifacts on github. Please either delete this release or create a new release with correct artifacts as it is breaking automated installs.

cafkafk commented 2 weeks ago

We have a weird issue with cross compilation right now, I couldn't find a fix in time. I'll turn this into a generic issue so I don't lose track of it.

rehanone commented 2 weeks ago

Is it possible to make the previous release latest on GitHub while this issue is being resolved? This is to fix the automated tools failing when trying to pull latest releases artefacts.

cafkafk commented 2 weeks ago

We may consider this depending on how long it takes to fix it. What systems specifically are breaking, for future reference?

rehanone commented 2 weeks ago

This is our internal automated deployment of vms based on ansible that pulls the latest binary from GitHub and deploys it on new VM instances.

nestor-custodio commented 2 weeks ago

I'll second that. Scheduled tasks on my suite of cloud development VMs would have broken if I'd been a little careless in writing my updaters for GitHub-sourced binaries.

I'll 100% grant that you are under no obligation to provide binary assets with releases on a project like this, but once you do make those available, there will invariably be tooling built with an expectation that they'll always be there going forward.

cafkafk commented 2 weeks ago

I'll 100% grant that you are under no obligation to provide binary assets with releases on a project like this, but once you do make those available, there will invariably be tooling built with an expectation that they'll always be there going forward.

I personally want to fix this but to be clear we do not provide any guarantees for release binaries existing (the various platforms and their random breakage, along with our essentially non existing funding makes this impossible to guarantee).

Adding binaries is a nice thing I'm doing to help users, but people should build their own binaries if they want something reliable, release binaries should not be load bearing, and tooling built with that expectation is inherently brittle. Not because I don't think it would be awesome if we could guarantee it, but we can't.

nestor-custodio commented 2 weeks ago

Absolutely fair. I've made a note to harden my updaters by building from source when a tool release lacks binary assets.

And to be clear: I do understand providing this tooling as ready-built executables is obviously an additional burden you're taking on for the benefit of end-users, and it is appreciated.

cafkafk commented 2 weeks ago

fwiw I think I fixed the issue with the build process, so we should have binaries on next release like normal (which will likely be next thursday but no promises)

rehanone commented 2 weeks ago

I am not sure if the project can completely remove itself from providing binary files. However, I would not push the point as it's an open source project by the end of the day.

There are automated tools that provide support for GitHub binaries explicitly. One such tool is

https://github.com/zyedidia/eget

cafkafk commented 2 weeks ago

I am not sure if the project can completely remove itself from providing binary files.

I mean we absolutely can, and with good reason. Our primary concern is to develop software, distribution of binaries is a distro level concern, and one we also do our best to accommodate when we cause breakage downstream (within reason).

For instance, we have "removed ourselves" from providing binaries for MacOS because we can't afford machines to compile on, and because the MacOS dev landscape is very inapproachable for people that aren't Mac users.

We instead offload those concerns to e.g. brew or nix, which are layers where it's way more appropriate to handle those issues.

I don't think we want to end up treating github as a distro, not just because it's not really what github is made for, but also because we want to be as forge agnostic as possible, in case github one day decides to go a direction that we find incompatible with the project.

This is also why we have avoided becoming over reliant on github specific features, and have preferred to build our dev and release process to be able to easily work on a local machine, and to be easily rewritten to another forge in the future, if necessary.

I will continue to create binaries whenever it's possible, but we will not guarantee them, and we will not consider missing binaries a blocking issue for releasing. This is just the same as us not blocking if bsd/windows/macos doesn't compile, those are issues, but they're not release blocking, distros will simply have to wait until those platforms are fixed. If we had more contributors to support those platforms, or a larger budget to do so, we would of course be able to ensure they were also working. But we don't sadly.

If this is an issue that affects Deutsche Bank directly, I would like to refer to my sponsor page and my email, I'm sure they can afford to pay a reasonable amount for the dev time required for such a guarantee :)