Fix nonzero exit for conda-build entrypoint

[kenodegard]

Description

Resolves #5167

Checklist - did you ...

• Add a file to the news directory (using the template) for the next release's release notes?
• Add / update necessary tests?
• Add / update outdated documentation?

[conda-bot]

Review build status

The workflow for building and uploading a canary release for conda-build with the label conda-conda-build-pr-5169 in channel conda-canary was started by @kenodegard!

Once it's done, use this command to try it out in a new conda environment:

conda install -c conda-canary/label/conda-conda-build-pr-5169 conda-build

• build 7791803435 succeeded on macOS (X64)

[mbargull]

Oh, I didn't even notice the .execute functions returned non-ints before; whoops!

Could we just let .cli.main_build.execute return 0 in any (non-failure) case?
Apart from the tests, I don't think we have consumers of that function that use the return value.

Yes, one could argue about API/deprecation etc..
I don't think this is necessarily needed here -- we do have the .api module and if anyone else uses .cli.main_*.execute they are knowingly doing bad stuff.
The proposed returns_outputs argument would just added unneeded potential maintenance burden, IMO.

[kenodegard]

Could we just let .cli.main_build.execute return 0 in any (non-failure) case?
Apart from the tests, I don't think we have consumers of that function that use the return value.

I'd prefer that, was just trying to avoid a larger refactor since this is a patch.

The proposed returns_outputs argument would just added unneeded potential maintenance burden, IMO.

Absolutely, not a fan at all.

@mbargull good feedback, I'll work some more on this

[mbargull]

LGTM!

[mbargull]

There are some sys.exit(x) instead of return x calls in those execute functions -- we could clean that up at some point; but not necessary to do in this PR.