Skip to content

Conversation

@elibosley
Copy link
Member

@elibosley elibosley commented Dec 16, 2025

…cess

  • Moved the 'release-please' job to run independently and added it as a dependency for the 'test-api' and 'build-plugin-staging-pr' jobs.
  • Updated permissions and checkout steps for the 'release-please' job to ensure proper execution on main branch pushes.
  • Enhanced workflow structure for better clarity and maintainability.

Summary by CodeRabbit

  • Chores
    • Optimized CI/CD pipeline configuration for improved release management workflow execution.

✏️ Tip: You can customize this high-level summary in your review settings.

…cess

- Moved the 'release-please' job to run independently and added it as a dependency for the 'test-api' and 'build-plugin-staging-pr' jobs.
- Updated permissions and checkout steps for the 'release-please' job to ensure proper execution on main branch pushes.
- Enhanced workflow structure for better clarity and maintainability.
@coderabbitai
Copy link
Contributor

coderabbitai bot commented Dec 16, 2025

Note

Other AI code review bot(s) detected

CodeRabbit has detected other AI code review bot(s) in this pull request and will avoid duplicating their findings in the review comments. This may lead to a less comprehensive review.

Walkthrough

The workflow reorganizes the release-please job to run earlier in the pipeline by moving it to the top-level jobs section and making the test-api job depend on it. A duplicate release-please job definition that appeared later in the workflow file was removed.

Changes

Cohort / File(s) Change Summary
Workflow job restructuring
\.github/workflows/main\.yml
Moved release-please job to the top-level with checkout (fetch-depth: 0) and googleapis/release-please-action@v4; added needs: release-please dependency to test-api job; removed the previously defined duplicate release-please job block with its permissions, steps, and outputs

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~3 minutes

  • Single-file workflow reorganization with straightforward job reordering
  • No logic changes or complex configuration additions
  • Consistent pattern: move job, update dependency reference, remove duplicate

Poem

📦 The rabbit hops through workflows with glee,
Reordering jobs with perfect harmony,
Release-please leads the way,
Dependencies dance in perfect display! 🐰

Pre-merge checks and finishing touches

✅ Passed checks (3 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The title accurately describes the main change: reorganizing the CI workflow to run the release-please job before other dependent jobs.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
✨ Finishing touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Post copyable unit tests in a comment
  • Commit unit tests in branch fix/release-please-first

📜 Recent review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between d13a1f6 and 088f239.

📒 Files selected for processing (1)
  • .github/workflows/main.yml (1 hunks)
🧰 Additional context used
🧠 Learnings (1)
📚 Learning: 2025-02-07T19:53:37.715Z
Learnt from: elibosley
Repo: unraid/api PR: 1125
File: .github/workflows/main.yml:233-233
Timestamp: 2025-02-07T19:53:37.715Z
Learning: In the plugin build workflow, the TAG environment variable (previously PR) is used for display purposes in OS releases, with "PR" prefix indicating it's from a pull request.

Applied to files:

  • .github/workflows/main.yml
🔇 Additional comments (1)
.github/workflows/main.yml (1)

18-35: Release-please job is well-structured but should not gate PR validation.

The job definition is correct for its intended purpose (running releases on main branch pushes). However, as noted in the previous review, making this a dependency for test-api will break PR testing since the job is skipped on pull_request events.

The structure is good, but the dependency chain needs adjustment to avoid breaking PR workflows.


Comment @coderabbitai help to get the list of available commands and usage tips.

@elibosley elibosley changed the title chore(ci): refactor GitHub Actions workflow to streamline release pro… chore(ci): run release please before other jobs Dec 16, 2025
Copy link

@chatgpt-codex-connector chatgpt-codex-connector bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Codex Review

Here are some automated review suggestions for this pull request.

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

Comment on lines 40 to 44
run:
working-directory: api
runs-on: ubuntu-latest
needs: release-please
steps:

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P1 Badge Avoid gating PR tests on release-please

The new needs: release-please on test-api makes all validation jobs depend on a job that only runs on push to main (see the if on lines 18‑21). On pull_request events release-please is skipped, and GitHub Actions skips any job whose dependency is skipped, so PR workflows will no longer run lint/type-check/tests or the plugin staging build at all. That removes CI coverage for incoming changes.

Useful? React with 👍 / 👎.

run:
working-directory: api
runs-on: ubuntu-latest
needs: release-please
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should we gate build-artifacts as well, or will only blocking one of them suffice? if it's a one or the other situation, i'd recommend blocking build-artifacts since the test run takes much longer.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants