ci(actions): restructure workflows to run release-please first

[AnnatarHe]

Summary

• Separate CI into two workflows matching the server pattern
• testing.yml: runs build, tests, coverage on every push/PR
• release.yml: runs release-please first, then build/verify/publish only when a release is created

Changes

• Deleted main.yml (old combined workflow)
• Created testing.yml for continuous testing
• Created release.yml with release-please running first

Test plan

• Verify testing workflow runs on PR
• Verify release workflow runs release-please on push to main
• Verify publish only triggers when release is created

🤖 Generated with Claude Code

[gemini-code-assist]

Note

Gemini is unable to generate a summary for this pull request due to the file types involved not being currently supported.

[claude]

Pull Request Review

Overview

This PR restructures the CI/CD workflows to separate testing from releasing, following a pattern similar to the server implementation. The changes improve workflow organization and efficiency.

✅ Strengths

1. Better Separation of Concerns: Splitting testing and release workflows is a solid architectural decision that aligns with CI/CD best practices.

2. Efficient Resource Usage: The release workflow now only runs build/verify/publish steps when a release is actually created, avoiding unnecessary work on every push to main.

3. Clear Workflow Names: Testing and Release are more descriptive than the generic CI name.

4. Proper Conditional Logic: Using if: ${{ steps.release.outputs.release_created }} ensures downstream steps only run when needed.

🔍 Code Quality Observations

Good Practices:

• Consistent use of checkout@v6, setup-java@v5, and other action versions
• Proper token and secret management
• Clear step naming
• Following Conventional Commits format in the PR title

⚠️ Issues & Suggestions

1. Wildcard Branch Trigger May Be Too Broad

# testing.yml lines 5-6
on:
  push:
    branches:
      - "*"

Issue: This triggers on ALL branch pushes, which could be excessive for personal/feature branches.

Recommendation: Consider being more selective:

on:
  push:
    branches:
      - main
      - develop
  pull_request:
    branches: [main]

Or if you want testing on all branches, document this decision in the workflow comments.

2. Missing Permissions Block in Testing Workflow

The release.yml properly declares permissions, but testing.yml doesn't specify any.

Recommendation: Add explicit permissions to testing.yml following security best practices:

permissions:
  contents: read
  pull-requests: write  # If you plan to comment on PRs with results

3. Verify Plugin Missing from Testing Workflow

The testing.yml runs buildPlugin and test, but doesn't run verifyPlugin which was in the original workflow.

Question: Was this intentional? The verifyPlugin task checks plugin compatibility and should probably run in CI to catch issues early, not just at release time.

Recommendation: Consider adding:

- name: Verify Plugin
  run: ./gradlew verifyPlugin

4. Redundant Build in Release Workflow

The release workflow runs buildPlugin again even though testing already built it.

Consideration: This is acceptable since the release is a separate workflow run, but if you wanted optimization, you could use workflow artifacts to pass the built plugin between workflows (though this adds complexity).

🔒 Security Review

✅ Good:

• Proper use of secrets.GITHUB_TOKEN and secrets.JETBRAINS_MARKETPLACE_TOKEN
• contents: write permission only on release workflow where needed
• No hardcoded credentials

✅ No concerns identified

🚀 Performance Considerations

1. Positive Impact: Release workflow now skips unnecessary steps when no release is created, saving CI minutes.

2. Consider: The jp-arm-oracle runner appears to be a self-hosted runner. Ensure it has capacity to handle parallel workflow runs if both testing and release workflows trigger simultaneously.

🧪 Test Coverage

No test files modified - This is expected for a CI/CD workflow change. However:

Test Plan Items: The PR description includes a test plan, but consider:

• Can you test the release workflow without actually creating a release? (Maybe in a fork/test environment)
• Consider documenting expected behavior in workflow comments

📋 Minor Suggestions

1. Add Workflow Comments: Consider adding a header comment to each workflow explaining its purpose:

# This workflow runs on every push/PR to validate code quality
# It performs build, test, and coverage reporting

2. Consistent Formatting: Both workflows use different indentation styles for branches: (lines 5-6 in each). Consider using the same style:

# Prefer this consistent style:
branches: [main]  # Or
branches:
  - main

3. Consider Workflow Badges: Update your README to show both workflow statuses if you have badges.

🎯 Summary

Recommendation: ✅ Approve with minor suggestions

This is a solid refactoring that improves CI/CD organization. The main issues are:

1. Potentially too-broad branch trigger in testing workflow
2. Missing verifyPlugin in testing workflow (may be intentional, please clarify)
3. Missing permissions declaration in testing workflow

These are minor issues that can be addressed in follow-up commits if desired, but they don't block merging.

---

Reviewed following: Conventional Commits format ✅, Project structure understanding ✅, CI/CD best practices ✅