CI/CD with GitHub Actions

Deploy on every push with the official GitHub Action: it packages a function directory, uploads it, streams build logs into the workflow run, and reports the result as a commit status and an optional pull-request comment with the preview URL.

Authentication is either keyless via GitHub OIDC (recommended — nothing to rotate) or a workspace API key stored as an Actions secret.

Minimal workflow

One step deploys the function; outputs expose the deploy id, status, and live URL for follow-up steps:

# .github/workflows/deploy.yml — keyless (OIDC) deploy on push, previews on PRs
name: Deploy to Inquir Compute

on:
  push:
    branches: [main]
  pull_request:

permissions:
  contents: read
  id-token: write       # GitHub OIDC token for keyless auth
  deployments: write    # GitHub Deployment records
  statuses: write       # commit status checks
  pull-requests: write  # sticky preview comment on PRs

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: inquir-compute/deploy-action@v2
        id: deploy
        with:
          path: ./functions/hello
          environment: ${{ github.event_name == 'pull_request'
            && format('preview-pr-{0}', github.event.number) || 'production' }}
      - run: echo "URL ${{ steps.deploy.outputs.url }}"

Keyless auth with OIDC

With OIDC the workflow exchanges a short-lived GitHub token for a 15-minute deploy token — no long-lived secret exists anywhere. Setup takes three steps:

• In your workspace settings, add the repository as a Trusted Repository, optionally pinning a ref pattern such as refs/heads/main.
• Grant the workflow id-token: write permission (see the example above).
• Omit api-key — the action detects OIDC automatically (oidc: auto); pass tenant only if the repository is trusted by more than one workspace.

API-key auth

Where OIDC is not available, create a workspace API key, store it as an Actions secret, and pass it as api-key: {'${{ secrets.INQUIR_API_KEY }}'}. Scope the key to deploys and rotate it like any other credential.

Per-PR preview environments

The environment input namespaces deploys, so pull requests can ship isolated previews that never touch production:

• On push to main the example deploys to production; on pull_request it deploys to preview-pr-N.
• With comment-on-pr: true (the default) the action maintains one sticky comment with the current preview URL.
• The commit status turns green only when the deploy reaches a terminal success state — failed deploys fail the check with the error attached.