HMS-10377: fix semantic release workflow

[TenSt]

This PR:

• updates semantic release workflow to create PR instead of direct commit
• creates new workflow that will create new release on push to main

Example PR:
#2123

[sourcery-ai]

Reviewer's Guide

Replaces the previous semantic-release workflow with two new GitHub Actions workflows: one to automatically bump the VERSION and open a release PR based on commit metadata, and another to create Git tags and GitHub releases from the VERSION file when changes land on main.

File-Level Changes

Change	Details	Files
Add scheduled/manual workflow to increment version and open a release PR.	Introduce release-create-pr workflow triggered weekly via cron and on manual dispatch. Check out the repository and read current VERSION value. Skip processing if the latest commit message already matches the current VERSION (avoids duplicate releases). Derive release type from the last line of the latest commit log and compute the next version via scripts/increment_version.sh. Update OpenAPI docs and clowdapp deployment files to the new version and write it back to the VERSION file. Create a draft release pull request using peter-evans/create-pull-request with a dedicated branch name, commit message, title and bot token.	.github/workflows/release-create-pr.yml
Add workflow to tag and create GitHub releases when VERSION changes on main.	Introduce create-release workflow triggered on pushes to main that modify the VERSION file. Check out the repository and read the tag name from the VERSION file, failing explicitly if it is missing. Create a GitHub release using softprops/action-gh-release, using the VERSION value as the tag name. Enable automatic release notes generation and mark the release as the latest.	.github/workflows/create-release.yml
Remove legacy semantic-release workflow in favor of the new release process.	Delete the previous semantic-release GitHub Actions workflow file to prevent conflicting or redundant release behavior.	.github/workflows/semantic-release.yml

---

Tips and commands

Interacting with Sourcery

• Trigger a new review: Comment @sourcery-ai review on the pull request.
• Continue discussions: Reply directly to Sourcery's review comments.
• Generate a GitHub issue from a review comment: Ask Sourcery to create an
  issue from a review comment by replying to it. You can also reply to a
  review comment with @sourcery-ai issue to create an issue from it.
• Generate a pull request title: Write @sourcery-ai anywhere in the pull
  request title to generate a title at any time. You can also comment
  @sourcery-ai title on the pull request to (re-)generate the title at any time.
• Generate a pull request summary: Write @sourcery-ai summary anywhere in
  the pull request body to generate a PR summary at any time exactly where you
  want it. You can also comment @sourcery-ai summary on the pull request to
  (re-)generate the summary at any time.
• Generate reviewer's guide: Comment @sourcery-ai guide on the pull
  request to (re-)generate the reviewer's guide at any time.
• Resolve all Sourcery comments: Comment @sourcery-ai resolve on the
  pull request to resolve all Sourcery comments. Useful if you've already
  addressed all the comments and don't want to see them anymore.
• Dismiss all Sourcery reviews: Comment @sourcery-ai dismiss on the pull
  request to dismiss all existing Sourcery reviews. Especially useful if you
  want to start fresh with a new review - don't forget to comment
  @sourcery-ai review to trigger a new review!

Customizing Your Experience

Access your dashboard to:

• Enable or disable review features such as the Sourcery-generated pull request
  summary, the reviewer's guide, and others.
• Change the review language.
• Add, remove or edit custom review instructions.
• Adjust other review settings.

Getting Help

• Contact our support team for questions or feedback.
• Visit our documentation for detailed guides and information.
• Keep in touch with the Sourcery team by following us on X/Twitter, LinkedIn or GitHub.

[github-actions]

SC Environment Impact Assessment

Overall Impact: ⚪ NONE

No SC Environment-specific impacts detected in this PR.

What was checked

This PR was automatically scanned for:

• Database migrations
• ClowdApp configuration changes
• Kessel integration changes
• AWS service integrations (S3, RDS, ElastiCache)
• Kafka topic changes
• Secrets management changes
• External dependencies

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 59.18%. Comparing base (7ad70af) to head (59a703b).

Additional details and impacted files

@@           Coverage Diff           @@
##           master    #2121   +/-   ##
=======================================
  Coverage   59.18%   59.18%           
=======================================
  Files         134      134           
  Lines        8622     8622           
=======================================
  Hits         5103     5103           
  Misses       2984     2984           
  Partials      535      535           

Flag	Coverage Δ
unittests	59.18% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[sourcery-ai]

Hey - I've found 2 issues, and left some high level feedback:

• The release-create-pr workflow uses actions/checkout@v6, which doesn’t exist and is inconsistent with @v4 used in the other workflow; update this to a valid, pinned version (e.g., @v4).
• In release-create-pr.yml, the PR base is set to master while the release workflow listens to changes on main; confirm the canonical default branch and make these workflows consistent.
• The Increment version step can exit 0 without setting VERSION_NEXT, but the subsequent PR creation still runs and will use an empty version; guard the PR step with a conditional (e.g., if: steps.version.outputs.VERSION_NEXT != '') and consider using git log -1 --pretty=%B when deriving RELEASE_TYPE to avoid including non-message lines.

Prompt for AI Agents

Please address the comments from this code review:

## Overall Comments
- The `release-create-pr` workflow uses `actions/checkout@v6`, which doesn’t exist and is inconsistent with `@v4` used in the other workflow; update this to a valid, pinned version (e.g., `@v4`).
- In `release-create-pr.yml`, the PR base is set to `master` while the release workflow listens to changes on `main`; confirm the canonical default branch and make these workflows consistent.
- The `Increment version` step can exit 0 without setting `VERSION_NEXT`, but the subsequent PR creation still runs and will use an empty version; guard the PR step with a conditional (e.g., `if: steps.version.outputs.VERSION_NEXT != ''`) and consider using `git log -1 --pretty=%B` when deriving `RELEASE_TYPE` to avoid including non-message lines.

## Individual Comments

### Comment 1
<location path=".github/workflows/release-create-pr.yml" line_range="19-25" />
<code_context>
+      - name: Checkout
+        uses: actions/checkout@v6
+
+      - name: Increment version
+        id: version
+        run: |
+          DOC_FILE="docs/v3/openapi.json docs/admin/openapi.json"
+          CLOWDER_FILE=deploy/clowdapp.yaml
+          VERSION=$(cat VERSION)
+          [ "$(git log -1 --pretty=%B)" == "$VERSION" ] && exit 0
+          RELEASE_TYPE=$(git log -1 | tail -n1) # Check release type (/major, /minor, /patch (default))
+          VERSION_NEXT=$(./scripts/increment_version.sh $VERSION $RELEASE_TYPE)
</code_context>
<issue_to_address>
**issue:** Early exit leaves VERSION_NEXT unset but later step assumes it exists

Because of the early exit, `VERSION_NEXT` is never set when the latest commit message matches the current `VERSION`, but the `Create PR for new release` step still references `steps.version.outputs.VERSION_NEXT`. This can produce empty/invalid branch names, commit messages, and PR titles. Add a guard like `if: steps.version.outputs.VERSION_NEXT != ''` to that step, or ensure `VERSION_NEXT` is set to a safe sentinel value before exiting early.
</issue_to_address>

### Comment 2
<location path=".github/workflows/release-create-pr.yml" line_range="16-17" />
<code_context>
+  tag-and-release:
+    runs-on: ubuntu-latest
+    steps:
+      - name: Checkout
+        uses: actions/checkout@v4
+
</code_context>
<issue_to_address>
**issue (bug_risk):** actions/checkout@v6 does not exist and will fail the workflow

`actions/checkout` currently only goes up to `v4`. Referencing a non-existent version like `@v6` will cause the workflow to fail because the action cannot be resolved. Please use a valid version (e.g. `actions/checkout@v4`).
</issue_to_address>

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.}