Actions Advisor

What is Actions Advisor?

Actions Advisor helps you improve the GitHub Actions workflows you already run. It projects every synced workflow in your organization into one estate, measures where that estate stands, and walks you through journeys that move it forward: standardizing copied workflows onto shared building blocks, recovering wasted Actions minutes, and climbing the SLSA supply-chain ladder. Each journey opens pull requests you review and merge; nothing changes in your repositories until you do.

Access it from the organization sidebar under Actions Advisor. It has five tabs:

• Overview — the three journeys, their headline numbers, and what is in progress
• Standardize — the Standardize journey: group copied workflows into patterns and converge them onto shared blocks
• Cost savings — the Cost journey: find and recover wasted Actions minutes
• SLSA — the SLSA journey: pin, attest, and route builds through a trusted build workflow
• Explore — browse every external action and reusable workflow referenced in your repositories

Only repositories activated in CodeCargo appear, and the estate is built from workflows on each repository's default branch. Agentic workflows are governed elsewhere and are excluded.

A project-scoped Actions Advisor page is also available under each project, with an Overview of action and workflow usage and the Explore tab, both filtered to that project's repositories. Journeys are organization-scope only.

Journeys

A journey is a guided improvement to your estate with a measurable objective. Every journey walks the same four steps on a stepper at the top of its tab:

Landing on a journey opens the step that holds the work; the ?step= parameter in the URL deep-links a step so you can share it.

Starting a journey

Each journey's Assess step explains what it does and offers Start journey. Starting freezes today's numbers as the journey's baseline and sets a default target: 100% for Standardize and Cost savings, and SLSA Build L2 for SLSA. You can change the target later from the Verify step. When more than one journey can start, the Overview offers Start together, which starts each with its default target; they run side by side.

Starting a journey requires the organization Admin or Architect role. The fixes a journey offers on its Plan step, whether batch pull requests or AI agent runs, can only be opened by an organization administrator. Anyone else can browse every step.

Verify, close, and start fresh

The Verify step shows the baseline frozen at start, the number today, and the target, with a day-by-day chart that fills in from daily snapshots — the first lands a day after the journey starts. Set target changes the goal; raising it can un-meet a met journey, lowering it can meet one.

When the target is reached the journey shows Target met (or Level reached for SLSA). From there you can Close and start fresh: the finished journey's result stays on record, and a new one measures from today's numbers. A journey can also be closed at any time from its menu; closing stops tracking progress without changing anything in your repositories, and offers to stop any agent runs still working.

Where journeys appear

• Actions Advisor → Overview shows a card per journey with its headline number, what that number is based on, a three-figure evidence strip, and a door into the journey. Journeys under way are listed in an In progress card with their current step and how far the number has moved.
• The organization dashboard shows the same three cards under What CodeCargo can do for you.
• Migration Assistant waves can carry a Standardize journey too. The GitHub estate is a managed wave that CodeCargo maintains for you and hides from the Migration Assistant wave and batch lists; its journey is the Standardize tab. A Jenkins or Azure DevOps wave's journey opens from the Actions Advisor at its own address.

Overview

The Overview tab is the three journey cards, an In progress list when any journey is live, and an estate strip counting workflows, repositories, distinct actions in use, and distinct reusable workflows called. Each card carries the journey's headline — percent standardizable, dollars or minutes recoverable, or the SLSA level every build reaches — and a line saying what the number is based on, such as when the estate was last read or how many workflows the rules have checked.

Explore

The Explore tab is the inventory of every external GitHub Action and reusable workflow referenced in your organization's repositories. A switch at the top reads the same inventory as Actions or as Reusable workflows; the old Actions Explorer and Workflows Explorer addresses redirect here. The sections below describe the Actions view; the Reusable workflows view differs only where noted.

View Modes

Toggle between two layouts using the buttons at the top:

• Split — a table on the left with a dependency graph on the right
• Table — a full-width data table with expandable rows

A search bar filters the list by action name.

Split View

In split view, clicking a row in the table loads an interactive dependency graph for that action:

• Root node — the action itself, showing its name, version count, and total usages, with a link to GitHub
• Version nodes — one node per version in use, color-coded by pinning type (green for SHA, blue for versioned, amber for unversioned)
• Repository nodes — the repositories and workflow files that reference each version

Hovering over a version node highlights all connected edges and repository nodes to show exactly which repos use that version.

The graph supports fullscreen mode for detailed inspection.

Interactive Graph Features

The dependency graph supports expand/collapse functionality to manage large numbers of references:

• Version nodes start collapsed and show a chevron indicator
• Expand a version to reveal its repository usage:
  • ≤8 repositories: Individual repository nodes appear
  • >8 repositories: An aggregation node appears with usage statistics
• Aggregation nodes provide:
  • Usage summary with repository count and file count
  • Searchable repository list with "N of M repos" footer
  • Scrollable content that doesn't interfere with graph zoom
• Smooth animations when expanding/collapsing nodes
• Viewport preservation — if you're zoomed in, expanding nodes won't disrupt your current view

The graph uses a four-column layout: root → version → usage summary → repository, making it easy to trace dependencies even with complex version distributions.

Workflow Navigation

Workflow entries in both the split view graph and table view provide direct navigation to their dependencies pages in CodeCargo:

• Repository file entries in the dependency graph display a popover when clicked, offering quick access to workflow code and dependencies
• Root nodes link to /workflows/{id}/dependencies for regular workflows
• Building Block workflows link to /building-block/workflow/{id}/dependencies
• Workflow code links navigate to the workflow's source code view when you have appropriate permissions

This provides seamless navigation from Actions Advisor to detailed workflow dependency analysis without leaving the CodeCargo platform.

Table View

In table view, each row shows an action with its versions (as badges), repository count, and usage count. Expanding a row reveals a detail table with:

Each expanded row includes links to view the workflow in CodeCargo or the action on GitHub.

Reusable Workflows

The Reusable workflows view has the same layout and functionality as the Actions view, but filters to reusable workflows instead of actions.

Key differences:

• Workflow entries display the filename (e.g., build.yml) as the primary label with the org/repo shown as a subtitle
• The expanded detail table does not include a Step column, since reusable workflows are called at the job level
• Links point to the workflow file rather than an action repository

Untracked Workflow Indicators

Workflows that cannot be resolved to a tracked CodeCargo workflow display a question mark (?) icon with a tooltip explaining "This workflow is not tracked by CodeCargo." This helps you identify:

• External workflows that aren't imported as Building Blocks
• Workflows on non-default branches that may be stale
• References to workflows that may have been moved or deleted

These indicators appear in both the dependency graph root nodes and repository file lists.

Building Block Source Filtering

The Reusable workflows view intelligently filters workflows from Building Block source repositories:

• Default branch sources: All workflows are shown since they overlap with normal workflow scanning
• Non-default branch sources (tags, feature branches): Only activated Building Blocks are shown to reduce noise
• Building Block indicators: Individual workflows that are Building Blocks display a Building Block icon, making it easy to distinguish them from regular workflows even when the entire repository is a Building Block source

This filtering ensures you see all relevant workflows while avoiding clutter from Building Block source artifacts that aren't actively used as Building Blocks.

Version Pinning

Actions Advisor uses color-coded badges to indicate how each reference is pinned:

SHA-pinning is the recommended practice because it ensures the exact code that runs cannot change without a deliberate update. Pinning every action is also the first rung of the SLSA journey, which opens the pull requests for you.

Standardize

The Standardize tab is the Standardize journey. It treats your GitHub organization as one estate, projected from workflows CodeCargo already syncs — there is no import step, and you don't pick a subset by hand. As workflows are added or removed, the estate refreshes in place. Renames and confirmed patterns survive a refresh; the scope does not, since the scope is the estate.

Viewing the estate is free and doesn't call AI. Launching an analysis and starting a convergence are separate permissions; if your role holds neither, you can still browse, and a banner explains what is withheld. The built-in Admin and Architect organization roles hold both.

Assess

Your estate today shows two percentages: standardizable, the share of your workflows that are near-copies of another one and so could share a building block, and standardized, the share of those that already call a shared building block instead of carrying their own copy of the steps. A bar breaks the grouped workflows down by how far each has come.

What we found lists the largest groups with their repositories, shared block, and stage, plus how many workflows already call an in-org reusable workflow and which shared blocks are called at more than one version. Click Start journey to freeze these numbers as the baseline, then Continue to Plan.

Plan

Similar workflows are grouped into patterns. Review each family, confirm it, and choose the reusable workflow or Building Block that the others should call. Confirming locks the grouping in place across planning re-runs — you can confirm a pattern before it has a convergence target, and its workflows are mapped automatically once one lands. Confirm all confirms every proposed pattern at once, skipping any whose Building Block blueprint still needs a destination.

Each pattern also offers Analyze this pattern, Edit, Set building block, Unconfirm, and Delete. Deleting a pattern reverts its members to ungrouped; the workflows themselves are untouched.

Existing reusable workflows (those that declare workflow_call) are destinations: they are what others converge onto. They are not added to convergence batches and are not rewritten as a pattern's template.

You can run a deeper analysis on the estate or on selected patterns when you want a richer grouping and a drafted plan. Deep analysis runs an AI agent in a read-only workspace over a sample of each pattern's workflows — it names and describes the pattern and drafts a Building Block recommendation. It takes a few minutes and uses AI tokens; plain pattern grouping does not call the model.

Journey requirements ride along. When the estate has a live Cost savings or SLSA journey, its requirements — caching, concurrency, and timeouts for Cost; pinned actions, hosted runners, and a pinned attestation step for SLSA — are passed to the planning and building-block producer prompts, so a block written during convergence already meets them. Once a block is produced, its pattern shows a chip per requirement saying whether the written block met it; a gap is a note, not a failure.

Execute

Once patterns are confirmed, generate batches and start convergence. Batch generation has two modes — Top up (the default) only adds workflows that aren't batched yet, while Start over discards generated batches that haven't started executing and rebuilds from the current patterns. You can include one-off workflows, and pilot mode carves out a small sample (three workflows by default) so you can review real pull requests before converging the rest. A batch of Building Blocks that still need to be produced runs first; workflows that call one wait for it rather than failing.

Each convergence run opens one agent workspace over one workflow and rewrites it to call its shared block, then leaves a pull request for review — nothing is merged for you, and nothing outside the batches is touched. The converged workflow keeps its name and its triggers and becomes a thin caller of the block; steps the block has no input for are kept alongside the call and reported as assumptions. Open optimization findings on those workflows are included in the same rewrite.

Track each batch as pull requests open, merge, or need a retry. The batch list and its members refresh on their own while anything is moving, and each member's status pill (Ready for review, PR open, and so on) links to its editor workspace. Failed runs are retried individually rather than re-armed by a new start. You can stop a run at any time to halt further changes — stopping un-arms members that haven't started and cancels active runs, and is reversible by starting again.

Verify

Verify shows the baseline standardized percent frozen at start, standardized today, and the target (converged workflows over grouped workflows, 100% by default), with the percent charted over time. Workflows left over from convergence — failed, skipped, or canceled — never reach converged, so they hold the percent below 100 and are called out here.

Cost Savings

The Cost savings tab is the Cost journey. It reads the workflow runs CodeCargo has already recorded, joins them with the findings your guardrails already stored, and shows where you are paying for Actions minutes that do nothing useful — then fixes what it can from inside the journey.

Minutes are estimates derived from each job's runner labels, and every surface that shows them says so; minutes on unclassified runners are reported as a share. Run history starts accumulating when CodeCargo begins receiving workflow runs and is never backfilled, so figures cover the days actually recorded (shown as "/ 9 days" until there are 30, then "/ mo") and the journey cannot start until some runs exist. Dollar figures use GitHub list price unless an admin enters your own Runner rates on the organization settings page.

Actions minutes are half the bill once agents are doing work too: track AI spend next to them, and cap it per organization or per user, under LLM Spend Controls.

Assess

Your spend today leads with the recoverable figure in dollars and minutes, alongside the total billed across the workflows with run data. A line beneath states what it is based on: how many days of run data and since when, the share of minutes on unclassified runners, how many workflows guardrails have evaluated, and which rates priced the figure. Four of the waste buckets depend on guardrail findings, so an estate with guardrails switched off reads cleaner than it is.

The recoverable headline sums only the two buckets the journey can attribute exactly — superseded runs and runaway jobs. The other buckets are shown as minutes at stake, since a fix recovers a share of them rather than the whole figure.

What we found lists each kind of waste:

Runaway jobs are measured against each job's own median, and workflows with a job whose normal run exceeds the 30-minute timeout are excluded so the fix cannot break them.

Plan

Plan is one list of fixes, grouped by method:

• Same edit in every workflow — one pull request per repository with the identical change: a cancelling concurrency block, a timeout-minutes: 30, or the cache input on the official actions/setup-node, setup-python, setup-java, and setup-go actions. Each row lets you choose the scope: only the workflows that wasted minutes in the window, or every workflow the rule flags.
• An AI agent rewrites each workflow — for the buckets with no edit that is safe everywhere, an agent reads each workflow, makes the change the row describes, and opens its own pull request. One run per workflow.

Tick the fixes you want; a summary beside Continue to Execute counts the fixes, the pull requests they will open at most, and what they are worth. The Move to Execute? confirmation names what opens where before anything starts. A single fix carries at most 500 workflows; larger buckets say "first 500 of N" and are fixed in rounds.

Execute

Execute lists the batch fixes and agent batches this journey started, with progress and a View pull request link per repository or workflow. Agent batches refresh on their own while runs are moving, and a no-op fix is recorded as skipped rather than failed.

Verify

Verify shows the projected saving frozen at start, the realized saving from pull requests that have merged, and the target share of the projection to recover before the objective counts as met. Both are monthly rates; a projection computed from fewer than 30 days of history is scaled to a month and says so. A chart tracks the minutes still recoverable day by day.

SLSA

The SLSA tab is the SLSA journey: show that your builds came from where they say they did, and reach the SLSA Build level you need. It is driven by a set of deterministic guardrail rules in the Supply Chain Provenance (SLSA) subcategory, which apply only to workflows that build and publish something — a release or tag trigger, a container image push, a package publish, or a release-creation step — and report not applicable everywhere else:

The existing GHASP2 pin-actions rule supplies the other Foundations requirement. See Workflow Compliance for how rules are evaluated and enabled.

The ladder

The level shown is the one every build workflow reaches, so one unpinned build holds the whole estate down:

Beside the ladder, a line reports how many deploy workflows verify provenance before deploying — not a level, but what makes the levels worth reaching.

Assess

Where your builds stand shows the level, how many build workflows publish something, and how many of the guarded workflows the SLSA rules have checked. Because the rules are new, an estate that has been scanned for months may still read Not checked yet; click Check N workflows to grade them (about 50 a minute, with the rest following through the regular sweep) and the page refreshes as results land. If guardrails are switched off for every workflow, the card offers Manage guardrails instead.

Once something has been checked, Pick the level to reach — Build L2 (the default) or Build L3 — and Start journey. What we found shows the ladder: how many builds reach each level, with the level the estate stands at today marked Current level.

Plan

Plan lists findings by the fix that closes them, from the bottom of the ladder up:

Select the fixes and Continue to Execute; the confirmation names what opens where. As with Cost, workflows owned by a confirmed Standardize group are fixed there instead, and each fix carries at most 500 workflows at a time.

Execute and Verify

Execute lists the pin batches and agent batches with their pull requests. Each merged pull request re-grades its workflow, so the level on Verify moves the same day. Verify shows the level at start, now, and the target, the ladder today with how many builds stand on each rung, and builds at the target level over time. The journey is met when every build workflow reaches the target level.

The Compliance Center's overview also shows a Supply Chain Provenance (SLSA) card with the ladder and a link to the journey.

Applying Workflow Fixes

Some fixes are the same small edit everywhere and can be opened as a batch, without an agent, from the Cost savings and SLSA journeys' Plan steps:

• Job timeouts — adds timeout-minutes: 30 to jobs that don't have one; jobs that already set a timeout, and jobs that call a reusable workflow, are left alone
• Concurrency cancellation — adds a workflow-level concurrency block that cancels superseded runs; workflows that already declare any concurrency are untouched (setting cancel-in-progress: false deliberately, as deploy workflows do, satisfies the rule)
• Dependency caching — adds the cache input to actions/setup-node, setup-python, setup-java, and setup-go steps, naming the package manager the job actually runs. A step is left alone, and the pull request says why, when the job names no manager or more than one, when the manager's lock file isn't committed, or when the step already sets cache. setup-go v4 and later cache by default and are skipped.
• Pin actions — replaces every third-party action's tag with the commit it points at today, keeping the tag as a comment (offered from the SLSA journey)

The dialog lists the exact repositories and workflows that will change before you start. Workflows in the same repository are changed together in one pull request, and each batch opens pull requests you review and merge like any other Actions update. Opening fix pull requests requires organization administration.

Actions Update

Actions Advisor includes an Actions Update feature that helps you manage and upgrade GitHub Actions versions across your organization. This functionality allows you to update action versions in bulk and maintain consistency across repositories.

Updating Action Versions

From the Explore tab, you can update actions to newer versions:

1. Select an action from the Explore table or dependency graph
2. Click "Update Action" to open the update dialog
3. Choose target repositories and workflows to update
4. Select the new version from available releases
5. Configure update options such as SHA pinning
6. Create update batch to process the changes

Update Batches

Actions updates are processed in batches that track progress across multiple repositories:

• Batch Status — shows overall progress and completion state
• Repository Progress — individual repository update status
• Pull Request Creation — automatic PR generation for each repository
• Error Handling — detailed error messages for failed updates

Version Selection

When updating actions, you can choose from:

• Latest Release — the most recent stable version
• Specific Version — a particular tag or release
• SHA Pinning — pin to a specific commit SHA for maximum security

The update process validates version compatibility and provides warnings for breaking changes or deprecated features.

Key Terminology

Pairs Well With