| 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:
- Project Name: Display name (e.g., "SonarCOBOL", "SonarApex")
- Plugin Name: Short identifier used in secrets (e.g., "cobol", "apex")
- Jira Project Key: Jira project key (e.g., "SONARCOBOL", "SONARAPEX")
- PM Email: Product Manager email address
- Slack Channel: Check the existing
release.yml for slackChannel value first - reuse it if present, otherwise ask the user
- Build System: Maven (pom.xml) or Gradle (gradle.properties)
- 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)
- CLI Integration: Whether to create an integration ticket for the SonarQube CLI scanner.
- 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:
-
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/
-
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)
-
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}"
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
