- name
- source-command-payload-job-deaggregate
- description
- Convert an aggregated release payload job back to a regular single-run job
# source-command-payload-job-deaggregate
Use this skill when the user asks to run the migrated source command `payload-job-deaggregate`.
## Command Template
# Deaggregate Release Payload Job
You are helping the user convert an aggregated release payload job back to a regular single-run job.
## Command Arguments
This command accepts optional arguments: `/payload-job-deaggregate [release] [stream] [arch]`
- If arguments are provided (e.g., `/payload-job-deaggregate 4.21 nightly` or `/payload-job-deaggregate 4.21 nightly arm64`), use them directly
- If no arguments are provided, prompt the user for the information
## Steps to follow:
1. **Get release, stream, and architecture**:
- If ARGUMENTS are provided, parse them to extract release version, stream type, and optional architecture
- If no ARGUMENTS are provided, ask the user for:
- Release version (e.g., "4.21", "4.20")
- Stream type (e.g., "nightly", "ci", "stable")
- Architecture (optional, defaults to amd64 if not provided)
- Supported architectures: `arm64`, `s390x`, `ppc64le`, `multi`, or leave blank for `amd64` (default)
Construct the file path based on stream and architecture:
- For `nightly` stream:
- Default amd64: `core-services/release-controller/_releases/release-ocp-{version}.json`
- Specific arch: `core-services/release-controller/_releases/release-ocp-{version}-{arch}.json`
- For other streams (ci, stable, etc.):
- Default amd64: `core-services/release-controller/_releases/release-ocp-{version}-{stream}.json`
- Specific arch: `core-services/release-controller/_releases/release-ocp-{version}-{stream}-{arch}.json`
Note: When architecture is specified and is not amd64, append `-{arch}` to the filename (after stream if present)
2. **Read the release file**: Load the JSON file to find all jobs in the `verify` section.
3. **Find aggregated jobs**: Identify all jobs that have `"aggregatedProwJob"` in their configuration. These are aggregated jobs.
4. **Present job selection**: Display a numbered list of all aggregated jobs found in the release file, showing both the job key, the Prow job name, and the current `analysisJobCount`. Organize jobs into logical categories (no more than 7 groups) based on platform or distinguishing characteristics. Maintain continuous numbering across all categories. Ask the user to provide the number of the job they want to deaggregate.
5. **Deaggregate the job**: Edit the selected job's configuration to:
- Remove the `"aggregated-"` prefix from the job key name (e.g., `"aggregated-gcp-ovn-upgrade"` becomes `"gcp-ovn-upgrade"`)
- Remove the entire `"aggregatedProwJob": { "analysisJobCount": N },` line (be careful with trailing commas)
- Ensure blocking jobs (those without `"optional": true`) have `"maxRetries"` set (typically 2)
- Keep all other existing fields like `"optional"`, `"upgrade"`, `"upgradeFromRelease"`, etc.
- Maintain proper JSON formatting
6. **Run make release-controllers**: Create a Python virtual environment if needed and execute `make release-controllers` to regenerate the release controller configurations. First check if `venv` directory exists - if not, create it with `python3 -m venv venv`. Then activate it with `source venv/bin/activate`, and finally run `make release-controllers`.
7. **Confirm completion**: Let the user know the job has been converted back to a regular single-run job and the configurations have been regenerated.
## Important notes:
- **Only modify files in `core-services/release-controller/_releases/` - DO NOT modify files in the `priv` directory as those are auto-generated**
- Deaggregating requires removing the `"aggregated-"` prefix from the job key name
- Deaggregating removes the `aggregatedProwJob` configuration, returning the job to single-run mode
- Blocking jobs (without `"optional": true`) must have `"maxRetries"` configured (typically 2)
- All other fields (blocking/informing status, upgrade configuration) are preserved
- The job will now run once per payload instead of multiple times with statistical analysis
- The JSON formatting must remain valid - be careful with commas
- Handle different stream types correctly (some releases don't have a stream suffix in the filename)
View on GitHub