feat: new arg to publish command

[dvarasani-crest]

Issue number:

PR Type

What kind of change does this PR introduce?

• Feature
• Bug Fix
• Refactoring (no functional or API changes)
• Documentation Update
• Maintenance (dependency updates, CI, etc.)

Summary

Added new argument --stage to ucc-gen publish command to enable users to use staging splunkbase to publish the package.

Changes

• No major changes. Just a new argument to existing command

User experience

• No change

Checklist

If an item doesn't apply to your changes, leave it unchecked.

Review

• self-review - I have performed a self-review of this change according to the development guidelines
• Changes are documented. The documentation is understandable, examples work (more info)
• PR title and description follows the contributing principles
• meeting - I have scheduled a meeting or recorded a demo to explain these changes (if there is a video, put a link below and in the ticket)

Tests

See the testing doc.

• Unit - tests have been added/modified to cover the changes
• Smoke - tests have been added/modified to cover the changes
• UI - tests have been added/modified to cover the changes
• coverage - I have checked the code coverage of my changes (see more)

Demo/meeting:

Reviewers are encouraged to request meetings or demos if any part of the change is unclear

[hetangmodi-crest]

Are we planning to expose this for all UCC users, or is this for a specific use case?

[github-actions]

Code Coverage ⚠️

Type	PR	Develop	Change	Status
Line Coverage	94.28%	94.37%	0.08%	🔴 Decreased
Branch Coverage	90.32%	90.50%	0.18%	🔴 Decreased

[kkedziak-splunk]

Review Summary

This PR adds a --stage flag to the publish command to allow publishing to staging Splunkbase. The approach of parameterizing the base URL is reasonable.

Issues found:

1. Naming convention: API_BASEURL uses SCREAMING_SNAKE_CASE inside a function body, which in Python conventionally indicates a module-level constant. Since this is a local variable, it should be api_base_url (snake_case) per PEP 8.

2. Generic Exception raised: In check_package_validation, a bare raise Exception(...) is used when validation fails. This should use a more specific exception class (e.g. RuntimeError or a custom PackageValidationError) so callers can distinguish validation failures from other errors.

3. Hardcoded staging URL inside function: The staging URL https://classic.stage.splunkbase.splunk.com/api/v1 is hardcoded inside a function. Consider extracting both base URLs as module-level constants for better maintainability.

4. Missing test for validation failure path: The new else branch in check_package_validation that raises Exception when result != "pass" has no unit test covering it.

5. --stage help text could be clearer: The help says "Whether to release the app on staging or production splunkbase" but it's a boolean flag. Suggested: "Publish to staging Splunkbase instead of production."

6. No changelog entry: Adding a new CLI flag is user-facing — does the project require a changelog entry for this?

[kkedziak-splunk]

API_BASEURL uses SCREAMING_SNAKE_CASE but this is a local variable, not a module-level constant. Per PEP 8 this should be api_base_url (snake_case).

[kkedziak-splunk]

Raising a bare Exception is too generic. Callers cannot distinguish a validation failure from other runtime errors. Consider using RuntimeError or a custom exception class like PackageValidationError.

[kkedziak-splunk]

The staging URL https://classic.stage.splunkbase.splunk.com/api/v1 is hardcoded inside the function body. Consider extracting both base URLs as module-level constants (e.g. SPLUNKBASE_API_URL and SPLUNKBASE_STAGE_API_URL) for better maintainability.

[kkedziak-splunk]

Help text says "Whether to release the app on staging or production splunkbase" but this is a boolean flag (present = staging, absent = production). Clearer wording: "Publish to staging Splunkbase instead of production."