automated-release-setup

name	automated-release-setup
description	Use this skill whenever the user asks to "set up automated release", "configure release automation", "add automated release workflow", or any variation of setting up the automated release workflow for a SonarSource analyzer project. This skill gathers project details, creates workflow files, updates existing release workflows, and sets up vault permissions.

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:

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)

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:

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)

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)

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