Commits & Deployments

Commits & Deployments view

The Commits & Deployments view displays one column for each repository. Repositories are grouped by organization and sorted alphabetically by repository name. Each repository column shows the repository’s main branch.

Clicking the repository name or the branch name opens the repository on GitHub in a new browser tab.

Below the branch name you can see the commit history of the main branch. Only commits that have been merged into the main branch are shown. Commits from other branches that have not been merged are not displayed.

To quickly find repositories, you can use the repository filter in the toolbar. The filter works the same way as in the Actions view.

Deployments

If a commit was deployed using GitHub’s Deployment API, a deployment tag appears on that commit. The tag shows:

• the environment name
• the deployment state

Both active and inactive deployments are displayed. Tags for inactive deployments appear lighter than active ones.

Each environment is assigned its own color. These colors do not have a specific meaning—they simply help distinguish environments visually.

The icon on the right side of the tag represents the deployment status.

A deployment tag can have one of the following states:

• Success
• Error
• In progress
• Waiting
• Skipped

If a log_url is set for the deployment environment, the tag links to that URL.

Triggering a deployment

To trigger a deployment for a commit, click the deployment button (the rocket icon on the right side of the commit entry).

The deployment dialog is only available if:

• deployment environments are configured
• the repository is not archived

Assume the following environments are configured:

dev
staging
production

The deployment dialog displays all environments along with their current state.

Deployments must follow the configured environment order. For example:

1. Deploy the commit to dev
2. After a successful deployment, deploy to staging
3. After that, deploy to production

Redeployments to previous environments (for example dev) are also possible.

A deployment can be triggered only if the following conditions are met:

• Deployments to required environments have completed successfully.
• No deployment is currently in progress for the selected environment (even for other commits).
• The commit is in a successful state. All GitHub check suites for the default branch must have completed successfully, except workflows listed in excluded-workflows.
• The commit history shown in the view is up to date. Otherwise, reload the page first.

Creating a deployment request

When triggering a deployment, And Action calls GitHub’s REST API to create a deployment. This creates a new deployment for the selected environment with the initial state pending.

The API request includes the following payload properties:

• auto_merge: false
• description: "Deployed via And Action"
• environment: The name of the environment (for example dev, staging, or production)
• payload: Additional metadata containing deployment_type, which can be one of:
  • forward
  • redeploy
  • rollback
• production_environment: true if the environment is live or production, otherwise false
• ref: The commit SHA

The deployment workflow

When a deployment is created on GitHub, it triggers a GitHub Actions workflow with the deployment event.

This workflow should:

1. Perform the actual deployment.
2. Update the deployment status:

• Set the state to in_progress when the deployment starts.
• Set the state to success or failure when it finishes.

3. Optionally set a log URL (log_url).

If log_url is set, And Action links the deployment tag in the Commits & Deployments view to that URL. Typically this URL points to the workflow run triggered by the deployment.

Example deployment workflow:

# <repository_root>/.github/workflows/deploy.yaml
name: Deploy
on: [deployment]

jobs:
  deploy:
    runs-on: ubuntu-22.04

    steps:
      - name: Set deployment state in progress
        uses: and-action/action-set-deployment-status@v1
        with:
          environment: ${{ github.event.deployment.environment }}
          state: in_progress

      - uses: actions/checkout@v3

      - name: Deploy
        # Perform the actual deployment to your infrastructure
        # (AWS, Heroku, Netlify, Vercel, etc.)

  set-state-success:
    runs-on: ubuntu-latest
    permissions:
      deployments: write

    if: success()
    needs:
      - deploy
    steps:
      - uses: and-action/action-set-deployment-status@v1
        with:
          environment: ${{ github.event.deployment.environment }}
          state: success

  set-state-failure:
    runs-on: ubuntu-latest
    permissions:
      deployments: write

    if: failure()
    needs:
      - deploy
    steps:
      - uses: and-action/action-set-deployment-status@v1
        with:
          environment: ${{ github.event.deployment.environment }}
          state: failure

Configuration options

Options for the Commits & Deployments view are defined under the deployment property in your andaction.yml file.

Two options are currently available:

• environments
• excluded-workflows

Example configuration:

deployment:
  environments:
    - name: dev
    - name: test
    - name: staging
      requires:
        - dev
        - test
    - name: production
      requires:
        - staging
  excluded-workflows:
    - Deploy
    - Manually deploy app

environments

The environments property defines the available deployment environments in the order they appear in the deployment dialog.

Each environment contains:

• a name
• optionally a list of required environments

Required environments must be deployed successfully before a deployment to the current environment is allowed.

In the example above:

• dev and test can be deployed at any time
• staging requires successful deployments to dev and test
• production requires a successful deployment to staging

excluded-workflows

To trigger a deployment, the commit must be in a successful state. This means all checks and workflow runs must have completed successfully.

Sometimes workflows should not be considered for this check—for example:

• manual deployment workflows
• workflows for demo or preview environments

These workflows can be excluded using excluded-workflows.

The list items refer to the workflow name defined inside the workflow file, not the filename.