feat: add --skip-all option

[jftuga]

If applied, this commit will all the user to include:

--skip-all

instead of having to include:

--skip-publish --skip-sign --skip-validate

Since this is a very simple patch, I am wondering if I may be missing something that would make this feature not work as expected.

[radeksimko]

I'm wondering what's the use case for this flag? Am I right that you want to use it to check "release-ability" - i.e. just build the executables?

If so, would it make more sense to turn this flag into --build-only, as --skip-all would perhaps (wrongly) imply that literally all steps are skipped?

[jftuga]

If this PR would be accepted if it was renamed to --build-only, I would gladly update the code.

[radeksimko]

I'm not a maintainer of GoReleaser so I don't get to decide what should be accepted, but I think that part of any good PR review process is understanding what problem is the PR trying to solve - hence I raised that question 😉

Am I right that you want to use it to check "release-ability" - i.e. just build the executables?

Maybe you had a different use case in mind - in which case your naming would make more sense?

[jftuga]

Yes, I just want to check "release-ability" of the built executables. To do this currently, I use all three --skip- options, which is tedious. I would like an easier way of doing this.

[caarlos0]

Yes, I just want to check "release-ability" of the built executables. To do this currently, I use all three --skip- options, which is tedious. I would like an easier way of doing this.

so, mainly, you just want to build the binaries and nothing else?

[jftuga]

so, mainly, you just want to build the binaries and nothing else?

Yes, I want the dist folder created with the binaries included. This way, I can do a final test of the binaries (locally) and also review the .tar.gz /.zip file contents before publishing to GitHub.

[radeksimko]

This way, I can do a final test of the binaries (locally) and also review the .tar.gz /.zip file contents before publishing to GitHub.

Do you mind explaining the motivation behind testing the archives in addition to testing the binaries? i.e. what kind of failure scenarios do you expect to find that you wouldn't find from testing the binaries directly?

---

We discussed addition of build subcommand in #1469 (comment) but I assume (given the name) such subcommand would not create archives.

In theory we could add archive subcommand in a similar vein, but that requires answering some questions:

• should such archive subcommand also automatically pre-build the binaries?
• should it rely on build subcommand, such that chaining build and archive works?
• what do we consider "archive"? Is it just the file archives, or all the other packages (NFPM, Snapcraft, Docker)?
• where does Homebrew and Scoop fall into this - should we also generate the formula/manifest as part of this step (without publishing it)?
• do we calculate checksums in this step, or should that be a separate command?
• do we also perform signing in this step, or should that be a separate command?

I think that the ability to run each stage (build, archive, publish) separately could offer some flexibility and possibly resolve the problem you are describing here, #1454 and #1469

Then each subcommand could just have its own few relevant skip flags (if at all any) and we could avoid the endless list of skip flags in the release command.

• release --skip-sign would be equivalent to build && archive (assuming archive doesn't do signing by default)
• release --skip-publish would be equivalent to build && archive && sign or build && archive --sign
• release would be equivalent to build && archive && sign && publish or build && archive --sign && publish

Understanding the use cases well would either way be helpful.

[jftuga]

@radeksimko,

Thank you for your well thought out, detailed post.

Do you mind explaining the motivation behind testing the archives in addition to testing the binaries? i.e. what kind of failure scenarios do you expect to find that you wouldn't find from testing the binaries directly?

I needed to test the archives when I wrote these PRs:

• feat: xz compression
• feat: use maximum compression for gzip and zip archives

Admittedly, these are one off scenarios. Moving forward, I sometimes need to include extra files, such as config files, within my archives. It would include one or two more files other than just README.md, LICENSE, and myPgm that you normally see within an archive. Before publishing to GitHub, I want to verify that I have all of the correct files within my archives.

We discussed addition of build subcommand in #1469 (comment) but I assume (given the name) such subcommand would not create archives.

In theory we could add archive subcommand in a similar vein, but that requires answering some questions:

Please consider my answers below with just a grain of salt as I have no strong opinions. Since I am not a full-time programmer, I can only estimate what would be the best outcome moving forward. Overall, I like the idea of having a archive subcommand.

• should such archive subcommand also automatically pre-build the binaries?

Yes. I think archive implies build, but build does not imply archive.

• should it rely on build subcommand, such that chaining build and archive works?

Yes, but if archive implies build, then you would just need to include archive in your goreleaser command line. However, it does seem strange to me that you would just run goreleaser archive ... without having the build verb in the command. I am not sure how to reconcile this.

• what do we consider "archive"? Is it just the file archives, or all the other packages (NFPM, Snapcraft, Docker)?

It includes all other packages as well as the file archives.

• where does Homebrew and Scoop fall into this - should we also generate the formula/manifest as part of this step (without publishing it)?

I don't know enough about these to give you an informed opinion.

• do we calculate checksums in this step, or should that be a separate command?

The archive subcommand should include these calculations.

• do we also perform signing in this step, or should that be a separate command?

Signing should be separate. Sometimes it is not necessary (or possible) to sign; therefore, I would separate this out.

I think that the ability to run each stage (build, archive, publish) separately could offer some flexibility and possibly resolve the problem you are describing here, #1454 and #1469

Quite possibly -- I am not sure.

Then each subcommand could just have its own few relevant skip flags (if at all any) and we could avoid the endless list of skip flags in the release command.

• release --skip-sign would be equivalent to build && archive (assuming archive doesn't do signing by default)
• release --skip-publish would be equivalent to build && archive && sign or build && archive --sign
• release would be equivalent to build && archive && sign && publish or build && archive --sign && publish

I will have to think more about the ramifications of these, but this seems overly complicated because it would be hard to remember. I also wonder if this would be too confusing.

Understanding the use cases well would either way be helpful.

I hope I answered your questions in enough detail. Please let me know otherwise.

[jftuga]

Upon further consideration, I don't think archive should imply build. If someone wants to do this, then they should issue two commands: first a build command and then an archive command. This seems like a more clean way to go about it.

[radeksimko]

🆒Thank you for all the detailed answers. I'd be willing to PR at least the build command (while paving the way for other commands as outlined), but I'll let some maintainers weigh in on the ideas here before jumping straight to implementation.

[radeksimko]

Upon further consideration, I don't think archive should imply build. If someone wants to do this, then they should issue two commands: first a build command and then an archive command. This seems like a more clean way to go about it.

That's what I was thinking too - it makes these different commands composable. The only downside is a bit more effort to implement it as all the artifacts are currently held in memory between steps, so we'd need to find a way of "re-discovering" the binaries in the dist folder during the archive step and re-discovering archives in potential sign/publish steps. I'm not sure if the composability outweighs the inner complexity, but it's probably fine if certain implementation details (like dist folder) are better documented and/or configurable.

[caarlos0]

Is this solved by goreleaser build? 🤔

[jftuga]

Is this solved by goreleaser build? 🤔

Yes, it is. I am closing this.

[ryancurrah]

@caarlos0 and @radeksimko adding to the conversation. An archive sub command would be useful to test that building the archives works. That way we can test that the release steps from build to archive will work before a change is merged to the master branch. I’m going to be integrating goreleaser into a project soon. Would it be worth opening a issue for this to document the desired behaviour of archive and I could potentially implement it?

[caarlos0]

@caarlos0 and @radeksimko adding to the conversation. An archive sub command would be useful to test that building the archives works. That way we can test that the release steps from build to archive will work before a change is merged to the master branch. I’m going to be integrating goreleaser into a project soon. Would it be worth opening a issue for this to document the desired behaviour of archive and I could potentially implement it?

I think goreleaser release --skip-publish would achieve what you want... (may also need --skip-validate)

[ryancurrah]

Thanks @caarlos0. If I run release afterwards with no skip arguments will it rebuild everything or use the existing artifacts?

[caarlos0]

It will start a fresh build.

[github-actions]

This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.