This creates a build_opts input along with some basic validation to ensure that duplicate options are not passed to buildbuild build.

• Add a new input for the action called build_opts
  • Pass that as the BUILD_OPTS environment variable to the image build step
  • Remove the line BUILD_OPTS="" (or it might need to be made conditional depending on whether the input has been added)
    • The input defaults to a single space. This allows us to pass it into the environment unconditionally.
    • Validation step prevents the action running with duplicate arguments.
    • For remaining arguments, bluebuild build errors should mention arguments explicitly added by the user as being the problem. So they should not be caught completely unawares that --nonexistent-arg is the problem.
• Do testing based on your custom branch, at least these two scenarios
  • Is BUILD_OPTS empty if you pass nothing into the build_opts input? (Build)[
  • Is it possible to break the build by adding some opts that conflict with what is automatically configured?
    • Yes. The build_opts and squash values are passed into a validation script that will exit with a non-zero status should the combination of inputs result in duplicate arguments. It also checks for -p or --push since the action provides that option by default.
  • Maybe we'd want to do an error message that points out that your custom build opts might be the issue in case of a build failure.
    • Builds fail fast at an initial validation step that explains what's wrong.
    • Checking for --push/-p even when squash is false
  • (of course try testing whether the input works for its actual use case too) Successful build using zstd compression