Skip to content

ci: run dependency review and license check on stacked PRs - #1478

Merged
reitblatt merged 2 commits into
mainfrom
reitblatt/ci-stacked-prs
Oct 29, 2026
Merged

reitblatt merged 2 commits into
mainfrom
reitblatt/ci-stacked-prs

Conversation

@reitblatt

@reitblatt reitblatt commented Oct 27, 2026 •

Copy link
Copy Markdown
Contributor

Context & Requests for Reviewers

Right now our PR workflows only trigger on pull_request with branches: [main], so stacked PR (whose base is another PR branch) doesn't run dependency-review, license checks until its parent merges.

Note: this doesn't include CodeQL, which is a configuration in the repo settings rather than a workflow setting. Right now it only runs on PRs based on main. It's a little tricky to turn that on for stacked PRs, because we'd either have move to the 'advanced setup' option with a workflow file that we then maintain, or turn on branch protection for stack branches (which has a lot of consequences for usability).

It also doesn't include AgentScan or Labeler, because those use pull_request_target and I'm hesitant to expand that. This means AgentScan may never run on a stacked PR, because I believe it only triggers on open/close events. Labeler will run when the stacked PR is rebased on main.

Tests

Tested on #1479 (throw-away PR stacked on this one).

Checklist

Only check items that apply to this PR; leave the rest unchecked.

  • If you changed anything user-facing (i.e. user interface or APIs):
    Did you update related docs?

  • If the change is notable (refer to Keep a Changelog conventions):
    Did you update CHANGELOG.md?

  • If you changed db/src/scripts/** and used CREATE TABLE, ADD COLUMN, or ALTER COLUMN:
    Are as many columns marked NOT NULL as possible? If some columns can sometimes be null depending on other columns, are there CHECK constraints capturing those relationships, and are these also reflected using unions in the associated Kysely types?

  • If you added a new signal in server/services/signalsService/signals/**:
    Did you classify every error case as a permanent error (SignalPermanentError, no retry) or a normal error (retryable)? Any case where the signal can't determine a score should be a SignalPermanentError.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@github-actions github-actions Bot added ci Deals with GitHub Actions, workflows, or continuous integration agentscan:mixed-signals labels Oct 27, 2026
@reitblatt
reitblatt marked this pull request as ready for review October 28, 2026 18:18
@reitblatt
reitblatt requested a review from a team as a code owner October 28, 2026 18:18

@cubic-dev-ai cubic-dev-ai Bot left a comment •

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

All reported issues were addressed across 3 files

Tip: Get a Slack DM when cubic finishes reviewing your PRs. Connect Slack

View guided diff | Turn on auto-fix | Re-trigger cubic

Comment thread AGENTS.md Resolved

@taobojlen taobojlen left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

LGTM!

For AgentScan, it's totally fine if it only runs on the furthest-downstack PR since (presumably) all the PRs in the stack will be authored by the same user.

Co-authored-by: cubic-dev-ai[bot] <191113872+cubic-dev-ai[bot]@users.noreply.github.com>
@reitblatt
reitblatt merged commit 420962b into main Oct 29, 2026
19 checks passed
@reitblatt
reitblatt deleted the reitblatt/ci-stacked-prs branch October 29, 2026 17:29
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

agentscan:mixed-signals ci Deals with GitHub Actions, workflows, or continuous integration

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants