automated-release-setup

# Setup Automated Release Workflow Help the user set up the automated release workflow by gathering required information and creating the necessary workflow files. ### Step 1: Gather Required Information Ask the user for the following details using AskUserQuestion: 1. **Project Name**: Display name (e.g., "SonarCOBOL", "SonarApex") 2. **Plugin Name**: Short identifier used in secrets (e.g., "cobol", "apex") 3. **Jira Project Key**: Jira project key (e.g., "SONARCOBOL", "SONARAPEX") 4. **PM Email**: Product Manager email address 5. **Slack Channel**: Check the existing `release.yml` for `slackChannel` value first - reuse it if present, otherwise ask the user 6. **Build System**: Maven (pom.xml) or Gradle (gradle.properties) 7. **SonarQube for IDE Integration**: Whether to create integration tickets for SonarQube for IDE: - **SLVS** (SonarQube for Visual Studio) - **SLVSCODE** (SonarQube for VS Code) - **SLCORE** (SonarLint Core) - **SLE** (SonarQube for Eclipse) - **SLI** (SonarQube for IntelliJ) 8. **CLI Integration**: Whether to create an integration ticket for the SonarQube CLI scanner. 9. **Version Bump**: Whether the automated release workflow should bump the project version after the release (i.e., prepare the next development iteration). If yes, also ask: - **Bump Version PR Labels**: Optional comma-separated list of labels to apply to the version bump pull request (e.g., `update-next-dev,skip-qa`). Leave empty if no labels are needed. ### Step 1b: Check Existing release.yml Before asking for all information, read the existing `.github/workflows/release.yml` file to extract: - **slackChannel**: Reuse the existing Slack channel configuration for the automated release workflow This ensures consistency between the release and automated-release workflows. ### Step 1c: Detect Workflow File Extension Before creating any workflow files, check whether the existing workflows in `.github/workflows/` use `.yml` or `.yaml` as the file extension: ```bash ls .github/workflows/ ``` - If most existing files use `.yml`, create new workflow files with the `.yml` extension. - If most existing files use `.yaml`, create new workflow files with the `.yaml` extension. - If there is a mix, prefer `.yml` (GitHub Actions default). Apply this detected extension consistently when naming all new workflow files (e.g., `automated-release.yml` or `automated-release.yaml`). ### Step 2: Check Prerequisites Remind the user of these prerequisites and **ask for confirmation** using AskUserQuestion: 1. **Jira Configuration**: - Add `Jira Tech User GitHub` as Administrator on the Jira project - Add the same user to Jira sandbox for dry-run testing (required for `dry-run: true` mode) - **Ask the user to confirm both**: - "Have you added 'Jira Tech User GitHub' as Administrator on the {JIRA_PROJECT_KEY} project?" (Production) - "Have you added 'Jira Tech User GitHub' as Administrator on the {JIRA_PROJECT_KEY} project in the Jira sandbox?" (For dry-run testing) - The user must verify this manually at: Project settings → People → Administrator role - Sandbox URL: https://sonarsource-sandbox-608.atlassian.net/ 2. **Vault Permissions** (re-terraform-aws-vault): - Create a PR to add the `release-automation` secret to the repository's config in the squad config file - File: `orders/{squad}.yaml` (e.g., `orders/analysis-jvm-squad.yaml`) - This creates secret `sonar-{plugin-name}-release-automation` - Example PR: https://github.com/SonarSource/re-terraform-aws-vault/pull/8406 - **Important**: The skill should create this PR automatically (see Step 5b) 3. **Release Workflow**: - Ensure `release.yml` supports `workflow_dispatch` with inputs: `version`, `releaseId`, `dryRun` ### Step 3: Create Workflow Files Create only the `automated-release` workflow file (using the detected extension from Step 1c). **Do not create a separate `bump-versions` workflow** — version bumping is handled directly by the reusable workflow when `bump-version: true` is passed. #### 3.1 Create `automated-release{EXT}` (standard, no SonarQube for IDE integration, no version bump) ```yaml name: Automated Release on: workflow_dispatch: inputs: short-description: description: "Short description for the REL ticket" required: true type: string sqc-integration: description: "Integrate into SQC" type: boolean default: true sqs-integration: description: "Integrate into SQS" type: boolean default: true branch: description: "Branch from which to do the release" required: true default: "master" type: string new-version: description: "Next Jira version to create after the release (e.g. 2.2), NOT the version being released; if left empty, the current Jira version's last component is incremented (e.g. 2.1 -> 2.2)" required: false type: string rule-props-changed: description: > "@RuleProperty" changed? See SC-4654 type: boolean default: false verbose: description: "Enable verbose logging" type: boolean default: false dry-run: description: "Test mode: uses Jira sandbox and creates draft GitHub release" type: boolean default: false jobs: release: name: Release uses: SonarSource/release-github-actions/.github/workflows/automated-release.yml@v1 permissions: statuses: read id-token: write contents: write actions: write pull-requests: write with: project-name: "${PROJECT_NAME}" plugin-name: "${PLUGIN_NAME}" jira-project-key: "${JIRA_PROJECT_KEY}" rule-props-changed: ${{ github.event.inputs.rule-props-changed }} short-description: ${{ github.event.inputs.short-description }} new-version: ${{ github.event.inputs.new-version }} sqc-integration: ${{ github.event.inputs.sqc-integration == 'true' }} sqs-integration: ${{ github.event.inputs.sqs-integration == 'true' }} branch: ${{ github.event.inputs.branch }} pm-email: "${PM_EMAIL}" slack-channel: "${SLACK_CHANNEL}" verbose: ${{ github.event.inputs.verbose == 'true' }} use-jira-sandbox: ${{ github.event.inputs.dry-run == 'true' }} is-draft-release: ${{ github.event.inputs.dry-run == 'true' }} ``` #### 3.2 Create `automated-release{EXT}` (standard, no SonarQube for IDE integration, **with version bump**) When the user wants version bumping, add `bump-version: true` (and optionally `bump-version-pr-labels`) to the `with:` block: ```yaml name: Automated Release on: workflow_dispatch: inputs: short-description: description: "Short description for the REL ticket" required: true type: string sqc-integration: description: "Integrate into SQC" type: boolean default: true sqs-integration: description: "Integrate into SQS" type: boolean default: true branch: description: "Branch from which to do the release" required: true default: "master" type: string new-version: description: "Next Jira version to create after the release (e.g. 2.2), NOT the version being released; if left empty, the current Jira version's last component is incremented (e.g. 2.1 -> 2.2)" required: false type: string rule-props-changed: description: > "@RuleProperty" changed? See SC-4654 type: boolean default: false verbose: description: "Enable verbose logging" type: boolean default: false dry-run: description: "Test mode: uses Jira sandbox and creates draft GitHub release" type: boolean default: false jobs: release: name: Release uses: SonarSource/release-github-actions/.github/workflows/automated-release.yml@v1 permissions: statuses: read id-token: write contents: write actions: write pull-requests: write with: project-name: "${PROJECT_NAME}" plugin-name: "${PLUGIN_NAME}" jira-project-key: "${JIRA_PROJECT_KEY}" rule-props-changed: ${{ github.event.inputs.rule-props-changed }} short-description: ${{ github.event.inputs.short-description }} new-version: ${{ github.event.inputs.new-version }} sqc-integration: ${{ github.event.inputs.sqc-integration == 'true' }} sqs-integration: ${{ github.event.inputs.sqs-integration == 'true' }} branch: ${{ github.event.inputs.branch }} pm-email: "${PM_EMAIL}" slack-channel: "${SLACK_CHANNEL}" verbose: ${{ github.event.inputs.verbose == 'true' }} use-jira-sandbox: ${{ github.event.inputs.dry-run == 'true' }} is-draft-release: ${{ github.event.inputs.dry-run == 'true' }} bump-version: true bump-version-pr-labels: "${BUMP_VERSION_PR_LABELS}" # omit this line if no labels ``` #### 3.3 Create `automated-release{EXT}` (with SonarQube for IDE integration, no version bump) ```yaml name: Automated Release on: workflow_dispatch: inputs: short-description: description: "Short description for the REL ticket" required: true type: string sq-ide-short-description: description: "Short description for the SonarQube for IDE tickets (leave empty to skip IDE tickets)" required: false type: string sqc-integration: description: "Integrate into SQC" type: boolean default: true sqs-integration: description: "Integrate into SQS" type: boolean default: true slvs-integration: description: "Create SLVS ticket (SonarQube for Visual Studio)" type: boolean default: false slvscode-integration: description: "Create SLVSCODE ticket (SonarQube for VS Code)" type: boolean default: false slcore-integration: description: "Create SLCORE ticket (SonarLint Core)" type: boolean default: false sle-integration: description: "Create SLE ticket (SonarQube for Eclipse)" type: boolean default: false sli-integration: description: "Create SLI ticket (SonarQube for IntelliJ)" type: boolean default: false branch: description: "Branch from which to do the release" required: true default: "master" type: string new-version: description: "Next Jira version to create after the release (e.g. 2.2), NOT the version being released; if left empty, the current Jira version's last component is incremented (e.g. 2.1 -> 2.2)" required: false type: string rule-props-changed: description: > "@RuleProperty" changed? See SC-4654 type: boolean default: false verbose: description: "Enable verbose logging" type: boolean default: false dry-run: description: "Test mode: uses Jira sandbox and creates draft GitHub release" type: boolean default: false jobs: release: name: Release uses: SonarSource/release-github-actions/.github/workflows/automated-release.yml@v1 permissions: statuses: read id-token: write contents: write actions: write pull-requests: write with: project-name: "${PROJECT_NAME}" plugin-name: "${PLUGIN_NAME}" jira-project-key: "${JIRA_PROJECT_KEY}" rule-props-changed: ${{ github.event.inputs.rule-props-changed }} short-description: ${{ github.event.inputs.short-description }} new-version: ${{ github.event.inputs.new-version }} sqc-integration: ${{ github.event.inputs.sqc-integration == 'true' }} sqs-integration: ${{ github.event.inputs.sqs-integration == 'true' }} create-slvs-ticket: ${{ github.event.inputs.slvs-integration == 'true' }} create-slvscode-ticket: ${{ github.event.inputs.slvscode-integration == 'true' }} create-slcore-ticket: ${{ github.event.inputs.slcore-integration == 'true' }} create-sle-ticket: ${{ github.event.inputs.sle-integration == 'true' }} create-sli-ticket: ${{ github.event.inputs.sli-integration == 'true' }} sq-ide-short-description: ${{ github.event.inputs.sq-ide-short-description }} branch: ${{ github.event.inputs.branch }} pm-email: "${PM_EMAIL}" slack-channel: "${SLACK_CHANNEL}" verbose: ${{ github.event.inputs.verbose == 'true' }} use-jira-sandbox: ${{ github.event.inputs.dry-run == 'true' }} is-draft-release: ${{ github.event.inputs.dry-run == 'true' }} ``` #### 3.4 Create `automated-release{EXT}` (with SonarQube for IDE integration **and** version bump) Add `bump-version: true` (and optionally `bump-version-pr-labels`) to the SonarQube for IDE variant's `with:` block, same as in 3.2. #### 3.5 Create `automated-release{EXT}` (with SQ-CLI integration, no version bump, no SonarQube for IDE integration) ```yaml name: Automated Release on: workflow_dispatch: inputs: short-description: description: "Short description for the REL ticket" required: true type: string cli-integration: description: "Create CLI ticket (SonarQube CLI scanner)" type: boolean default: false sq-cli-short-description: description: "Short description for the CLI ticket (leave empty to use the main short-description)" required: false type: string sqc-integration: description: "Integrate into SQC" type: boolean default: true sqs-integration: description: "Integrate into SQS" type: boolean default: true branch: description: "Branch from which to do the release" required: true default: "master" type: string new-version: description: "Next Jira version to create after the release (e.g. 2.2), NOT the version being released; if left empty, the current Jira version's last component is incremented (e.g. 2.1 -> 2.2)" required: false type: string rule-props-changed: description: > "@RuleProperty" changed? See SC-4654 type: boolean default: false verbose: description: "Enable verbose logging" type: boolean default: false