[Bug]: make goreleaser fails to build a .deb file
#1404
Comments
hax0rbana-adam
added
bug
needs triage
|
Hey @hax0rbana-adam, may I ask why you're trying to build a |
I don't see how these would be relevant to it breaking on the |
|
The gcloud is only a barrier to using the Makefile to build deb packages, however packaging also fails when trying to run Making gcloud optional would address half of the issue while still allowing your release process to work unchanged. The other half of the fix are the changes to .goreleaser.yml, as they are required to build is even after the gcloud dependency is removed. This was verified using v1.24 of the go compiler (the latest available in Debian Trixie). As to the question on why I was trying to build a .deb package locally, it started because the the installation page indicates that the only packages available are AMD64 despite binaries being available for arm64. So I expected that I'd need to package it up myself. It was only later that I found the arm64 .deb package. If the instructions were updated to explain that there are arm64 packages, or if #660 were addressed and the documentation was updated to instruct people to use the 3rd party apt repo, this confusion would be eliminated. However, one of the major benefits of using open source projects is that people can build & package the code them themselves. If the project is ever abandoned, which is extremely common, it's vital that users be able to build & package the code. The same is true if people want to do end-to-end testing when they make a code change before submitting their patch upstream. This is, of course, a philosophical argument with which people may not agree. I've managed to build the .deb files locally and done my best to offer the patches upstream to offer this capability to others. I don't like having to get rid of using variables, so I hope that someone will build on my improvements and preserve the ability to use them before merging this into the default branch. Maybe there's just some compiler flag that is needed or something? |
|
There was work in flight updating the docs for getting the repositories setup. The page is now updated: https://smallstep.com/docs/step-cli/installation/#linux-packages-amd64. We'll need to keep the We depend on Goreleaser Pro, which is not something just anyone would do or is willing to pay for. That is why you needed some more changes to the Makefile, as those are not supported in the normal version. We might update some of the Makefile to make it simple to run |
|
The installation page still says the Linux Packages are AMD64, with no mention of ARM in that heading nor section. Here's what it looks like for me:
Thanks for filling me in on why I had to make changes to the yml file in order to get goreleaser to work. That all makes sense. I. Would you be willing to accept a contribution of an additional .yml file that people could use to build a .deb package themselves? If so, I'm willing to submit a pull request with that change and documentation to explain how to build it. II. Would you be willing to accept a modification to the Makefile add a goreleaser-local target, which would not require gcloud? I'd also include documentation on how to do so. My proposed change is to leave the roreleaser target exactly the same so your release process would not be affected. |
If I understood my colleagues correctly, it should also support ARM64.
That would be nice. But see remark below; might need to go after that.
This is on my plate. |
|
WIP: #1408 Could you give that a try, @hax0rbana-adam? More changes may be necessary, but I wanted to keep the changes minimal to not incur a lot more maintenance burden. |
|
That fixed the ability to FYI: |
For most purposes the current PR should be sufficient. The goal of the new target is not to make it full parity with our CI releases; just to make it easier to run the release process locally while debugging and updating things etc. You did point out some failures with our
I've pushed some additional commits, incl. a fix for that download URL. When I used Pro locally without a license (afaik), it succeeds building the binary when using There are some additional changes in the Makefile to help with an edge case affecting the behavior of OSS vs. Pro (which might in fact be a bug in GoReleaser). It is thus possible to use both OSS and Pro now, but |
|
According to the documentation, the Smallstep apt repo does not include any .deb files for ARM64. I don't know if that's an oversight in spinning up the apt repo, or an oversight in updating the documentation. step-cli docs and step-ca docs If the AMD64 & ARM64 packages are both available from the Smallstep apt repo, I agree that it is much less important for people to be able to build their own .deb package. However, there are many situation where it is still useful:
The title of this issue still holds. Using the makefile, one still can not create a .deb file. However, with the improvements in #1408, it's extremely close to being able to create a .deb file locally using an undocumented build process. The following was tested on Debian Testing (trixie). git clone https://github.com/smallstep/cli
cd cli
sudo apt install -y golang
git checkout herman/goreleaser-improvements
make bootstrap
# Work around gcloud requirement
export PATH=~/go/bin:$PATH
printf '#!/bin/sh\necho $@\n' > ~/go/bin/gcloud
chmod +x ~/go/bin/gcloud
GPG_PRIVATE_KEY_FILE="" goreleaser release --snapshot --clean --skip sign
find . -name '*.deb'Without the environment variable, goreleaser fails with the following error (despite the the If build instructions are added which include building .deb files, I'd consider this ticket to be resolved even though the process is not as easy as running The real intent of this ticket was to make sure people could create their own .deb files. As long as there's a documented way to do so, that takes care of my concern. Even just publishing the build instructions above would suffice, even with the peculiarities of making a script called |
It should be there. At least that's my understanding of talking to my colleagues. Should thus just be a simple change to the docs. I'm not daily driving Linux, nor am I installing
These all sound plausible, but in my opinion don't necessarily warrant maintaining support for the release process to be performed outside of environments that we control. The first is acceptable, but in the end if you want to test a patch, a binary can be created with
Try adding
Instead of defining the environment variable before executing the build, it seems possible to use the
While I appreciate your concerns, the time you put into figuring out a working local release process and describing all of it at length in this issue, I believe it's a bit of a niche use case. It's not one of our primary interests to let everyone build their own releases in every format easily, let alone in environments that we don't control. The release process primarily exists for us to release software, and if there's ever a need for someone else to release our software, they can use their own release process and tooling if needed. There's more to it than just building a With the additional changes applied as described above I think the process could be as simple as |
|
I've pushed another change in #1409. With GoReleaser Pro, It looks like OSS won't work at the moment, because neither |
|
I can confirm that the GPG_PRIVATE_KEY_FILE no longer needs to be defined. Running And I can confirm that the OSS version fails with Thank you for the detailed response to my other points. It helps me understand where you're coming from and why the process and documentation for build one's own .deb packages is unlikely to be made as easy as I'd like. I've been burned by open source projects being abandoned and then being unable to reproduce all the artifacts enough times that I do try to build most things myself and contribute the changes upstream to make it easier for others to do the same. I'm using step-cli and step-ca for my own personal infrastructure for myself and some family & friends. No employees, no money, just enjoying TLS and SSH certs signed by my private CA. 😀 My payment for using open source software is to host an apt repo for projects until they get their own, file quality bug reports and send any patches I develop upstream. It's not a big lucrative contract, but it's what I have to offer. |
Steps to Reproduce
git clone https://github.com/smallstep/clicd clisudo apt install -y golangmake bootstrapmake goreleaserYour Environment
stepCLI Version - bfab777Expected Behavior
A .deb package would be build locally without needing to register an account with Google.
Actual Behavior
Additional Context
I installed
gcloudto illustrate that the .deb file can not be built even with this installed. Ifgcloudis not installed, the error message is as follows:To fix this, "variables" and "check_boxes" need to be removed from .goreleaser.yml (patch below) then
goreleaser release --snapshot --clean --skip signwill get further.I'm not sure why the .goreleaser.yml file needs the above modifications, but
goreleaser releasewill refuse to run as long as those are there. Mainly I just wanted to provide a workaround that would allow people to build their own .deb package locally until this can be fixed properly.After the workaround is applied, the .deb files are there:
Contributing
Vote on this issue by adding a 👍 reaction.
To contribute a fix for this issue, leave a comment (and link to your pull request, if you've opened one already).
The text was updated successfully, but these errors were encountered: