Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

package subcommand #3697

Open
2 tasks done
lengau opened this issue Jan 15, 2023 · 1 comment
Open
2 tasks done

package subcommand #3697

lengau opened this issue Jan 15, 2023 · 1 comment
Assignees
Labels
enhancement New feature or request pro

Comments

@lengau
Copy link

lengau commented Jan 15, 2023

Is your feature request related to a problem? Please describe.

While adding a new packaging format to an app or investigating a packaging specific bug, it's often necessary to run the packaging step several times to configure it correctly. This often doesn't require rebuilding the executable, but rather just edits to the .goreleaser.yaml file and re-packaging. .

Describe the solution you'd like

A package subcommand would make this far easier. The following options would be nice for me:

  • --nobuild - don't build, just use the existing binary in the dist directory. (Or default to --nobuild and have a --build to re-run the build.)
  • A way to select which packaging/archive format to use, and potentially which platform. Perhaps a combination of packaging type (e.g. nfpms or snapcrafts), ids, and other specifics (such as GOOS, GOARCH and maybe formats)?

Describe alternatives you've considered

My current solution is as follows:

  1. Comment out all builds/releases in .goreleaser.yaml except the one I want to use.
  2. Set any goos and goarch values to be strictly the platform I want to package for.
  3. Start making changes
  4. Test those changes with goreleaser release --snapshot --rm-dist

A package subcommand could replace that with, for example, goreleaser package --nobuild --single-platform snapcrafts to package the already-built software as a snap for my current platform.

Search

  • I did search for other open and closed issues before opening this.

Code of Conduct

  • I agree to follow this project's Code of Conduct

Additional context

The most relevant other issue I found was #3219. I think a package subcommand would solve that use case as well.

@lengau lengau added enhancement New feature or request triage Issue pending triage by one of the maintainers labels Jan 15, 2023
@caarlos0
Copy link
Member

this is a good idea, although not sure how simple to do.

in any case, if done, will be in pro only, as the oss version does not have what's required for it to work.

@caarlos0 caarlos0 added pro and removed triage Issue pending triage by one of the maintainers labels Feb 10, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request pro
Projects
None yet
Development

No branches or pull requests

2 participants