Call for Maintainers
caarlos0 opened this issue · 34 comments
I honestly barely make the time to maintain nfpm and goreleaser.
At this point, I'm not even sure the way we're handling this was a good idea. Maybe it would be better to make this a pipe on goreleaser? We discussed it a few times, but never really did it.
Anyway, this issue is to inform that I will no longer add new features to this.
Will try my best to keep it more-or-less working.
If anyone wants to maintain this, feel free to ping me here.
cc/ @goreleaser/everyone @client9
Well yes, it would make sense because the download config is determined by the goreleaser config. So we'd encourage people to use both and they could provide the downloader script within the same repository with each release.
One question: do you want to support repositories which do not have a .goreleaser.yml -> naked repos ?
One question: do you want to support repositories which do not have a
.goreleaser.yml-> naked repos ?
AFAIK no "naked" repos are using godownloader, so I would say to drop it...
Or we encourage repos to use goreleaser :) (git-chglog/git-chglog#58)
Then they could ship the download script within the repository, easily create it.
Hey everybody,
I was surprised to see the "not actively maintained" notice on the README.
To be honest, it feels to me that the noticed is a bit exaggerated. A project doesn't need to have dozens of commits per week to be considered "maintained", it just needs to work. It's fine to not add new features and focus on stability.
I've been using godownloader for a while and I never noticed any bugs or problems.
That said, I could consider helping if this project is really dying, despite having limited time (as everyone does).
And yeah, merging this into goreleaser itself may be a good idea. It depends on how it'd be easier to maintain it.
I love goreleaser & godownloader 💓
I cannot actively maintain it either, but probably I can help to some extent if it helps.
I honestly barely make the time to maintain nfpm and goreleaser.
Just to confirm, does it mean godownloader instead of goreleaser, right?
Are you looking for maintainer for goreleaser too?
Are you looking for maintainer for goreleaser too?
so far only for godownloader...
Just like @haya14busa I'm happy to help keep this project alive.
I'd suggest
- merging
godownloaderintogoreleaser - dropping support for "naked" repos
- allowing generation of .sh file from
-f, --config=.goreleaser.yml(instead of only the remote-fetching-r) - supporting Arm in godownloader:
archives:
# This works:
- name_template: '{{.ProjectName}}-{{.Os}}-{{.Arch}}'
# This fails, godownloader complains about .Arm
- name_template: '{{.ProjectName}}-{{.Os}}-{{.Arch}}{{if .Arm}}v{{.Arm}}{{end}}'- allowing generation of Go code, functionally equivalent to Shell generated code, so that
gorelease-d binaries can compile this file in and hot-swap themselves (it works!) - skip install if checksum file shows binary is already on local machine
- a flag replacing
-b <bindir>orBINDIR=<bindir>to install the binary in one of the user-writable places of$PATH.
I am down to work on these as soon as the first 2 are done ;)
I'm also a very happy user of godownloader and would be happy to assist in maintainership.
@fenollp re:
allowing generation of .sh file from -f, --config=.goreleaser.yml (instead of only the remote-fetching -r)
For info, this is already possible by passing the config file as the first positional argument to godownloader (at least on the latest master, I haven't checked other versions).
Concretely, I'd propose to tackle @fenollp's first two bullet points in reverse order:
- "dropping support for "naked" repos" can be done with a PR to this repo.
- "merging godownloader into goreleaser" should probably happen after. With a bit of git magic, I think we can even preserve the full history of godownloader when it's merged into goreleaser.
@caarlos0 would you be up for this?
https://stackoverflow.com/a/10548919/1418165 can help with number two.
Stack OverflowConsider the following scenario:I have developed a small experimental project A in its own Git repo. It has now matured, and I'd like A to be part of larger project B, which has its own big repos...
I had a plan in mind but I greatly simplified it recently... but it will be a little opinionated:
- merge this into goreleaser, dropping support for everything but goreleaser (no more naked repos and etc)
- each time goreleaser runs, upsert to .sh files in a repo (can be the same repo or in another one):
my-app-v1.2.3.shmy-app.sh(which is the latest)
this way, on every release, we will both have a file for the specific release and on file that we can instruct users to use to always install the latest version.
This solves a couple of problems, because once the file is generated, it is there for good:
- it doesn't matter which version of goreleaser was used to generate the sh file, its there and good to go
- easily install old versions by just changing the URL
the downside is that eventually the user will have A LOT of .sh files... which, sure, they can manually remove... but yeah, its a simple solution that seems to handle all problems. Am I missing something? WDYT?
BTW Thanks for the interest everyone, I would definitely love some help to make this work - whatever "this" means in the end 🙏
I think it is a great way (simplest way?) to tackle the issue of "I want to install version 1.2.3 but that script from master doesn't work because someone modified goreleaser.yml since v1.2.3". A scary problem. With this one has the two covered: How do I install latest version (1) & How do I install this specific version (2).
This adds quite a bunch of files to source control but their size is minimal. Some projects may not even care about (2) and should be able to opt-out.
Also their should be a way to check if godownload-v1.2.3.sh was indeed checked-in when building that tag.
https://stackoverflow.com/a/10548919/1418165 can help with number two.
I'd suggest Git Subtree to merge repositories and keep the history. I did that in the past with great success.
Stack OverflowConsider the following scenario:I have developed a small experimental project A in its own Git repo. It has now matured, and I'd like A to be part of larger project B, which has its own big repos...
This issue seems be stale, will auto-close soon.
not stale
@caarlos0 I actively contribute to the Jenkins organization and this project is really amazing, would love to help maintain it if required. Thanks for the amazing work, cheers
@caarlos0 Maybe disable the autoclosing of issues on this repo, especially while godownloader is not getting active maintenance?
Just because an issue has not been touched in 7 days does not mean that it is not a bug or does not contain useful information.
Forgot this action, will disable it as well
I'm still not sure what to do about this... there are so many open issues on goreleaser and I haven't make the time to think about this one yet.
Didn't want to leave you folks without a response, so there you have it, although its not a good response, I know.
Sorry about that
🚧 Is this repo looking for support?
Hello, we created this issue becuase the user @sospedra told us you are calling for maintainers.
✅ If you're looking for collaborators no action is required.
👮🏻♂️ If this repo is well-supported please put a comment here sospedra/rfm#65 and we'll close it immediately.
Sorry for any inconvinience. We understand this message can feel spammy but we really think is good to double-check first with the current owners :)
I understand why the project is no longer actively maintained, I do indeed think that it's not goreleaser's task to try and auto-detect release downloads.
What I've been using goreleaser for however is to generate the install.sh for my projects which use goreleaser. This is very handy because it makes stuff bash/curl-able. It would be great if this feature could either be merged into goreleaser or furthered as godownloader with a new scope. I also have very little time because of other projects I maintain, but because this is so useful I'd be happy to help as best as I can!
I wrote this very crude Go package https://github.com/FuzzyMonkeyCo/monkey/tree/master/pkg/update
that fetches + checksums binaries published to github with goreleaser.
It ends by replacing the running executable, loads and runs it to display the new version string. I guess one can think of this as hot swapping.
I'd love for this package to be part of upstream :)
Hi,
I've been using godownloader for a while on many projects. I found it useful and I will be pleased to help. I don't have strong opinion on either we should merge it into goreleaser or not. But if not, I can help maintaining it.
A good start could be :
- a better documentation : I still find it hard to install godownloader, the readme lack of a install section
- having a look at what others do : for example, godownloader download the binary in a
bindirectory created in the working dir. Which means the developers have to copy the binary to a directory in their path. Maybe we should find a solution to make it directly available. It could be in a/usr/local/bindirectory par example.
Let me know if you have other stuff in mind.
* having a look at what others do : for example, godownloader download the binary in a `bin` directory created in the working dir. Which means the developers have to copy the binary to a directory in their path. Maybe we should find a solution to make it directly available. It could be in a `/usr/local/bin` directory par example.
this is already possible (-b), but as you mentioned, documentation is lacking...
I think the first thing we can start doing is removing the support for other repos that are not using goreleaser... then we can decide the rest...
You mean all the experimental support?
You mean all the experimental support?
yes... then we can start refactoring things until we are ready to merge with goreleaser's repo (or not, in any case it would be better)
Alright. I'll try to find time during the week to push a PR.
Hi @caarlos0
I've been looking at the source code. I understand well how to remove experimental supports.
But there is something I don't get: what's the goal of the tree feature? Did you have the goal of creating some kind of index of all projects that use goreleaser?
The tree was an idea at the time, we can keep it for now, but I don't intend to do so in the long term, if you prefer I can create a new branch (develop, v2 or something like that) and we work on that one, once its done we see what we do about this...
Good idea. Let's create a v2 branch. Then we will merge each PR in this branch and, in the end, we could create a V2.
v2 created
Something i've often wondered about is whether goreleaser could publish a standard-format manifest file, which cannot be configured differently. This could be formatted in a way that would make the install.sh script much simpler to build/maintain
Okay, I'm officially deprecating this.