ENGINEERING
Run only the affected test suite for a GitLab dependency MR
Instead of running the whole CI suite on a dependency bump, this triggers a targeted GitLab pipeline scoped to just the tests that exercise the changed packages.
How it runs
The automated pipeline, trigger to output.
- TriggerGitLab MR webhook on dependency-bump branchGitLab
- ActionExtract changed packages from lockfile diffGitLab
- ActionResolve affected test targets from dependency graphPostgres
- ActionTrigger scoped GitLab pipeline with job filterGitLab
- LogicWait for pipeline result
- OutputPost pass/fail status and gate label on MRGitLab
What it does
A full CI run on every Renovate MR wastes minutes and money. This workflow computes the minimal set of test jobs that actually cover the bumped dependency, triggers a scoped GitLab pipeline against that subset, and reports pass/fail back to the MR as a gate.
When to use it
Use it when your monorepo CI is slow and most dependency MRs only touch a corner of the codebase. It cuts feedback time from 30 minutes to a couple, while still proving the bump is green where it matters.
How it works
- 1A GitLab MR webhook fires for a branch matching your dependency-bump naming convention.
- 2The workflow extracts the changed packages from the lockfile diff.
- 3It queries Postgres for the test targets that transitively depend on those packages and builds a job filter.
- 4An action triggers a new GitLab pipeline with that filter passed as a CI variable, so only the affected jobs run.
- 5A logic step waits for the pipeline result.
- 6On green it posts a passing status and a `dep:tests-green` label; on red it posts the failing job links and blocks the MR.
Set it up
What you configure once, before turning it on.
- 1Connect GitLabRepos, MRs, pipelines, registry.
- 2Connect PostgresAny Postgres URL — query, write, migrate.
- 3Set each agent's modelWe leave models unset so you pick the tier — fast + cheap, or top-quality.
- 4Tune it to your dataEdit the prompts, filters, and field mappings so it matches how your team works.
- 5Test, then turn it onRun once against a sample, confirm the output, then enable the trigger.
More Engineering workflows
Gate breaking API PRs behind downstream consumer acknowledgement
When a PR introduces a breaking contract change, comments the impact summary back on the PR, applies a blocking label.
Publish a versioned API changelog to Confluence on each release tag
On a new semver release tag, gathers the contract changes since the last release and writes a clean.
Agent reviews model-license fit and suggests compliant swaps on the PR
When a PR adds a Hugging Face model, an agent reads the model card and license, judges fit against your commercial-use policy.
Upgrade Impact Router to Module Code Owners
Maps a dependency-bump PR's affected modules to their CODEOWNERS, then DMs each owner on Slack with only the changelog slice that touches code they own.
Re-Voice IVR Prompts on Phone-Tree Config Merge
When a phone-tree config change merges in GitHub, regenerates the ElevenLabs audio for any prompt whose script changed in the diff and opens a follow-up PR adding the new audio…
Upstream Release to Notion Upgrade Brief
When a watched package publishes a new release, fetches the release notes, maps them to the internal modules that depend on it.
Run it inside a business
This workflow drops into a full company template. Import the org, and this is one of the playbooks its agents run.
Run this workflow in your colony.
14-day trial. No DevOps. No Sales call. Provisioned in under a minute.