Help string should not be output if it fails

[rosaLux161]

Description

The help string should only be output if incorrect parameters are specified and not if the command fails for other reasons.

Try 'semantic-release version -h' for help.:

$ semantic-release --strict version
5.2.10
Usage: semantic-release version [OPTIONS]
Try 'semantic-release version -h' for help.
Error: No release will be made, 5.2.10 has already been released!

That the help string is output every time, it's unclear whether you have made a mistake with the parameters yourself or whether the tool has failed for other reasons.

Use cases

For example: in --strict mode, so that a pipeline aborts if no release is created and twine does not attempt an upload and aborts because the dist folder has not been created.

Addendum: Is there a best practice on how to set this up? Strict-mode the correct choice?

[codejedi365]

Good catch! I thought I had resolved this but I guess not completely.

Yes, --strict is exactly there for that reason.

An alternative if you don't like a failed job for a non-release is to embed a multi-line script statement that just uses a bash if-statement to prevent the call to twine and catches failed exit code.

release:
  script:
    - # ...
    - if semantic-release version --strict --print; then 
        semantic-release -vv version;
        twine upload ...;
        semantic-release -vv publish;
      fi 

GitLab will automatically fold this into a single line, so you must have semicolons on each internal if line.

[codejedi365]

One problem with this is that if it fails for some other reason (an exception is thrown or auth fails), the exit code is squashed and the job succeeds

I updated the post from earlier. Use the --print option to basically run a test run for a version. It has a higher likelihood of success without errors and gives a better exit code flag for use.