# Workflows

---

## Overview

Every push automatically creates a searchable release with full traceability -- no tokens or secrets needed.

A workflow is a GitHub Actions workflow file (`.github/workflows/*.yml`) that defines your CI/CD pipeline. When configured with the Fly action, a workflow becomes the bridge between your code and Fly's release tracking.

Once configured, every push automatically publishes artifacts to Fly Registry and creates a release with an AI-generated summary, linked PRs, commits, and full traceability -- no tokens or secrets needed.

---

## How It Works

### Configuration Model

Configuring a workflow means adding two things to the workflow YAML file:

**OIDC permissions** for secure, token-free authentication:
```yaml
permissions:
  contents: read
  id-token: write
```

**Fly action** to configure package managers on the CI runner:
```yaml
- uses: jfrog/fly-action@v1              # Setup Fly package managers
```

For Docker and Helm, the Fly action exports your registry hostname as `FLY_REGISTRY_SUBDOMAIN` (e.g., `acmecorp.jfrog.io`), so your image path becomes `acmecorp.jfrog.io/docker/my-app:tag`. See [Automate Releases →](../../developer-workflow/ci-cd/) for full configuration details.

### Configuration Status

Each workflow has one of two states:

**Configured** -- The workflow includes the Fly action. It can push and pull artifacts from Fly Registry, creates releases automatically, and has full traceability.

**Not Configured** -- The workflow exists but isn't using Fly. Artifacts aren't tracked and no releases are created.

### What Happens After Configuration

Once merged, every push that runs the workflow:
1. Authenticates with Fly Registry via OIDC (no tokens needed)
2. Publishes artifacts to Fly Registry
3. Creates a release with AI-generated summary, linked PRs, commits, and artifacts
4. Produces a job summary with collected artifacts and transfer results
5. Notifies Fly when the CI session ends for proper session tracking

---

## From Your Coding Agent

The recommended way to configure workflows is through your coding agent. Fly scans your workflow files, generates the changes, and opens a pull request -- no manual YAML editing required.

### Configure All Workflows

*"Configure my workflows with Fly"*

Fly scans your `.github/workflows/*.yml` files and opens a pull request with the required changes. Review, merge, and you're done.

### Configure a Specific Workflow

*"Configure this workflow for Fly Registry"*

Opens the current workflow file and adds the Fly action and permissions.

### Manual Configuration

Add the OIDC permissions block at the top level (after `on:`, before `jobs:`) and the Fly action step within your job (after setup steps, before artifact operations).

[Full examples →](../../developer-workflow/ci-cd/)

---

## In Fly Web

Fly Web shows the configuration status of all workflows in each repository, so you can quickly see which workflows are connected to Fly and which still need setup.

### Workflow List

Navigate to **Git Repositories** → select a repository → **Workflows** tab.

| Column | Description |
|--------|-------------|
| **Workflow Name** | Name from the workflow YAML file |
| **File Path** | Location in `.github/workflows/` |
| **Status** | Configured or Not Configured |
| **Last Run** | Most recent workflow execution |
| **Runs** | Total number of executions |

### Actions

- **Configure Workflow** -- Opens the coding agent flow or links to manual configuration
- **View on GitHub** -- Opens the workflow file directly on GitHub

---

## Next Steps

- [Releases →](../releases/) - What workflows produce
- [Git Repositories →](../git-repositories/) - Repositories that contain workflows
- [Automate Releases →](../../developer-workflow/ci-cd/) - Full CI/CD configuration guide with examples