Actions Advisor

What is Actions Advisor?

Actions Advisor helps you standardize the GitHub Actions workflows you already run. It gives you organization-wide visibility into every GitHub Action and reusable workflow referenced across your repositories, projects those workflows into one estate, groups similar ones into patterns, and opens pull requests that converge them onto a shared reusable workflow — closing common reliability issues in the same change.

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

• Overview — usage, pinning, and version-sprawl summary
• Actions Explorer — browse every external action referenced in your repositories
• Workflows Explorer — the same, for reusable workflows
• Standardize — group workflows into patterns and converge them onto shared blocks

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 the Overview and Explorer tabs filtered to that project's repositories. Standardize is organization-scope only.

Overview

The Overview tab provides a high-level summary of actions and workflow usage across your organization.

Summary Statistics

Four stat cards at the top show:

• Unique Actions — distinct external GitHub Actions referenced
• Unique Workflows — distinct reusable workflows referenced
• Repositories — number of repositories with action or workflow references
• SHA-Pinned — percentage of all references that are pinned to a commit SHA

Top Actions & Workflows

A horizontal bar chart shows the most-used actions and workflows ranked by total usage count across all repositories.

Version Pinning Strategy

A donut chart breaks down how references are pinned:

Version Distribution

A table lists actions and workflows that have multiple versions in use across your repositories (version sprawl). This helps identify targets that should be consolidated to a single version. Columns include the target name, versions in use (shown as badges), number of repos, and total usages.

Actions Explorer

The Actions Explorer tab lets you browse and inspect every external GitHub Action referenced in your organization's repositories.

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.

Workflows Explorer

The Workflows Explorer tab has the same layout and functionality as the Actions Explorer, 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 Workflows Explorer 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. The SHA-Pinned percentage on the Overview tab tracks your organization's progress toward this goal.

Standardize

The Standardize tab 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.

Standardize has three views, switched at the top of the tab: Patterns, Convergence, and Insights. A summary line above the switcher tracks progress, for example "12 patterns across 340 convergeable workflows · 7 of 12 confirmed."

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.

Patterns

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.

Convergence

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. 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.

Insights

The Insights view measures the estate and points at what's worth standardizing or fixing first:

• Adoption and duplication — Building Block adoption percentage, adoption candidates (workflow families that could call an existing block), and duplicated workflows
• Version sprawl — the same action pinned to different versions across repositories
• Optimization findings — deterministic guardrail findings across the estate, with one-click fixes where available (see Applying Workflow Fixes)
• What the estate costs to run — estimated runner minutes, failure rate, and the costliest pattern, over the last 30 days

Minutes are estimates derived from each job's runner labels, and every surface that shows them says so; self-hosted runners count as zero. Run history starts accumulating when CodeCargo begins receiving workflow runs and is never backfilled, so cost tiles fill in as the estate runs. When run data exists, the Patterns view can also sort patterns by estimated run time, so the most expensive families surface first.

Optimization findings come from the Workflow Structure & Performance guardrail rules and require guardrails to be enabled on the repository; the card always states how many workflows were evaluated out of how many exist. The rules covered are:

Applying Workflow Fixes

Some optimization findings can be closed without a full convergence run. From a finding, choose the affected workflows and open a fix batch:

• 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)

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 Actions Explorer, you can update actions to newer versions:

1. Select an action from the Actions Explorer 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