fix(analyze): return integer exit code from analyze_boot

[nanookclaw]

Problem

cloud-init analyze boot always exits with return code 1, even on successful analysis.

The user reports return_code=1 with stderr=successful, which is the symptom.

Root Cause

analyze_boot returns a string status code ("successful", "failure", or "container"). This return value flows through sub_main → main → sys.exit(). In Python, sys.exit(string) prints the string to stderr and exits with code 1 — even when the string is "successful".

Fix

Return an integer exit code instead of the string status code:

• 0 for SUCCESS_CODE and CONTAINER_CODE (analysis succeeded)
• 1 for FAIL_CODE (analysis failed)

This is consistent with the other analyze subcommands (analyze_blame, analyze_show, analyze_dump) which all return None, which sys.exit() correctly treats as exit code 0.

Testing

Updated tests/unittests/analyze/test_boot.py:

• test_container_no_ci_log_line: asserts 1 == finish_code (was FAIL_CODE)
• test_container_ci_log_line: asserts 0 == finish_code (was CONTAINER_CODE)

Fixes #4245

[github-actions]

Hello! Thank you for this proposed change to cloud-init. This pull request is now marked as stale as it has not seen any activity in 14 days. If no activity occurs within the next 7 days, this pull request will automatically close.

If you are waiting for code review and you are seeing this message, apologies! Please reply, tagging blackboxsw, and he will ensure that someone takes a look soon.

(If the pull request is closed and you would like to continue working on it, please do tag blackboxsw to reopen it.)

[nanookclaw]

Canonical CLA is now signed for nanookclaw / nanook@agentmail.to. I don't have permission to rerun the failed upstream CLA check from my side; could you rerun it when convenient?

[nanookclaw]

Rebased onto current main and corrected the commit author email to the address registered under the Canonical CLA, so the prior CLA-check failure (which matched the old users.noreply.github.com author) should now resolve once the workflows are approved to run.

The earlier build failure was an unrelated CI toolchain issue (ModuleNotFoundError: No module named 'python_discovery' from a virtualenv/tox install on Python 3.14), which the rebase onto current main should also clear.

The PR's workflows are currently in action_required (first-time-contributor gate). Whenever a maintainer has a moment to approve the run, it should pick up the corrected CLA and updated base. Thanks!