> ## Documentation Index
> Fetch the complete documentation index at: https://docs.weaveos.com/llms.txt
> Use this file to discover all available pages before exploring further.

# GitHub Actions

> Track GitHub Actions workflows and deployments

GitHub Actions integration is automatically enabled when you connect your GitHub organization to Weave. No additional setup required.

## What's tracked

### Workflow runs

* All workflow executions across your repositories
* Job statuses (success, failure, cancelled, skipped)
* Execution duration and timing
* Trigger events (push, pull\_request, schedule, manual)

### Deployments

* Production deployments detected from workflow jobs
* Deployment frequency and success rate
* Deployment environments and targets
* Rollback detection

### Build health

* Build failure patterns
* Performance trends

## DORA metrics enabled

Connecting GitHub Actions enables these key DevOps metrics:

* **[Deployment frequency](/metrics/ci-deploy-frequency)** — How often you deploy to production
* **[Deploy success rate](/metrics/ci-deploy-success-rate)** — Percentage of successful deployments
* **[MTTR](/metrics/ci-deploy-mttr)** — Mean time to recovery from failed deployments
* **[Deploy lead time](/metrics/pr-deploy-lead-time)** — Time from code commit to production

## Deployment detection

Weave identifies production workflows using the existing production-workflow setting and detection behavior. For workflows without deployment-confirmation jobs configured, workflow completion remains the existing deployment signal.

### Confirm actual production work

For a workflow where success can include a skipped release, configure one or more exact deployment-confirmation job names in the workflow's production deployment settings. Choose the fully qualified GitHub job names that prove the production release was applied and verified. Include every job that participates in the declared production release; a wrapper, approval, baseline lookup, staging preparation, or notification job is not proof that code reached production. Workflows with independent release domains should configure all applicable confirmation jobs together, or use separate workflow labels when the domains are genuinely independent.

When confirmation jobs are configured, the overall workflow's success is insufficient. The selected confirmation work must have run successfully. If the overall workflow succeeds and all matching configured jobs were skipped, it is a successful no-op and is not counted as a deployment. A failed overall workflow remains a failed CI attempt in deployment metrics. If no matching job ran, or the job list is missing or incomplete, deployment evidence remains unknown/pending and is surfaced for reconciliation; it is not silently treated as a deployment or as proof that no deployment happened. Notification failures do not erase a separately verified release.

### Attribute changes in batch releases

Use **Batch releases since** only when a later release can be tied to a verified prior baseline and its complete deployed commit range. This lets Weave attribute canceled or superseded changes to the first confirmed batch release that contains them. A later successful workflow by itself does not establish that it included an earlier change. If the baseline or full commit comparison cannot be verified, cumulative attribution stays unresolved rather than fabricating PR links. Direct PR associations continue to work independently.

Changing labels does not itself establish historical coverage. Previously stored runs may need their attempt-specific jobs and release ancestry reconciled; missing evidence stays pending until that work succeeds.

## Automatic setup

<Steps>
  <Step title="Connect GitHub">
    GitHub Actions data is automatically synced when you connect GitHub to Weave
  </Step>

  <Step title="Verify tracking">
    Deploy once and check that Weave detects the workflow run
  </Step>

  <Step title="Configure environments">
    Mark production environments in Weave settings if needed
  </Step>

  <Step title="View metrics">
    Access DORA metrics in Overview and Reports pages
  </Step>
</Steps>

## Supported features

### Workflow analysis

* Execution time trends
* Job-level performance tracking
* Step duration analysis
* Resource usage patterns

### Deployment tracking

* Environment-specific deployment history
* Deployment annotations on PR timeline
* Rollback and revert detection
* Deployment frequency trends

### Integration with PRs

* Link deployments to merged PRs
* Calculate deploy lead time per PR
* Track which commits are deployed
* Monitor PR-to-production flow

## Troubleshooting

<AccordionGroup>
  <Accordion icon="magnifying-glass" title="Deployments not detected">
    If deployments aren't showing up:

    1. Check that environment names match production patterns
    2. Verify workflows are deploying from tracked branches (usually `main`)
    3. Ensure commit SHAs are included in deployment events
    4. Review production environment configuration in Weave settings
  </Accordion>

  <Accordion icon="chart-line" title="Incorrect metrics">
    If DORA metrics seem wrong:

    1. Verify the workflow is marked as a production workflow
    2. For workflows that can succeed without releasing, check the configured confirmation job names
    3. Review unknown or pending job evidence and cumulative batch-release coverage in deployment settings
    4. Check that staging/preview workflows are excluded and deployment timestamps are accurate
  </Accordion>

  <Accordion icon="clock" title="Delayed sync">
    If workflow data is delayed:

    1. Verify GitHub webhooks are configured correctly
    2. Check that Weave has proper permissions
    3. Ensure workflows are completing (not stuck)
    4. Trigger manual sync from Data page
  </Accordion>
</AccordionGroup>

## Data synced

Weave tracks only workflow metadata:

* Workflow and job names
* Execution status and duration
* Trigger events and actors
* Environment names and deployment targets
* Commit SHAs and references

**We never access:**

* Workflow file contents
* Step logs or console output
* Environment variables or secrets
* Application code or artifacts

## Best practices

### Clear environment naming

Use consistent, clear names for production environments:

* ✅ `production`, `prod`, `live`
* ❌ `prod-1`, `production-us-east-1`

### Deploy from main

Deploy from a single main branch for accurate lead time tracking:

* Merge PRs to `main`
* Deploy `main` to production
* Avoid long-lived release branches

### Atomic deployments

Each deployment should represent a discrete set of changes:

* Deploy one PR or a small batch
* Avoid mixing many unrelated changes
* Configure confirmation jobs that prove the selected production work completed
* Enable clear failure attribution

## Related documentation

* [Deployment frequency metric](/metrics/ci-deploy-frequency)
* [Deploy success rate metric](/metrics/ci-deploy-success-rate)
* [Deploy MTTR metric](/metrics/ci-deploy-mttr)
* [Deploy lead time metric](/metrics/pr-deploy-lead-time)
* [GitHub integration](/code-platforms/github)


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.