apify-ci-integration

Configure CI/CD pipelines for Apify Actor builds and deployments. Use when automating Actor deployment via GitHub Actions, running integration tests against the live Apify API, or building CI/CD for scrapers that push to the Apify platform. Trigger with "apify CI", "apify GitHub Actions", "apify automated deploy", "CI apify", "apify pipeline", "auto deploy actor".

Allowed Tools

WriteBash(gh:*)Bash(npm:*)

Provided by Plugin

apify-pack

Claude Code skill pack for Apify (18 skills)

saas packs v1.5.0
View Plugin

Installation

This skill is included in the apify-pack plugin:

/plugin install apify-pack@claude-code-plugins-plus

Click to copy

Instructions

Apify CI Integration

Overview

Automate Apify Actor builds, tests, and deployments using GitHub Actions —

test-on-PR, deploy-on-merge, live-API integration testing, and Docker build

verification. Three workflow files do the work (test, deploy, verify-build);

full copy-paste-ready definitions live in

references/workflows.md.

Prerequisites

  • GitHub repository with Actions enabled
  • Apify API token stored as a GitHub secret
  • Actor code in the repository

Authentication

CI authenticates to Apify with a personal API token, never a hard-coded

credential:

  • Store the token as a GitHub Actions secret (gh secret set APIFY_TOKEN),

and expose it to a job only via env: APIFYTOKEN: ${{ secrets.APIFYTOKEN }}.

  • The Apify CLI reads it as apify login --token $APIFY_TOKEN; the REST API and

apify-client read it from the APIFY_TOKEN environment variable.

  • Use separate APIFYTOKENTEST / APIFYTOKENPROD secrets so integration

runs never touch production data. Get tokens from Apify Console → Settings →

Integrations.

Instructions

Step 1: Configure GitHub Secrets


# Store Apify token for CI
gh secret set APIFY_TOKEN --body "apify_api_YOUR_CI_TOKEN"

# Optional: separate tokens for test vs production
gh secret set APIFY_TOKEN_TEST --body "apify_api_test_token"
gh secret set APIFY_TOKEN_PROD --body "apify_api_prod_token"

Step 2: Create the test workflow

Add .github/workflows/apify-test.yml with two jobs — unit-tests on every PR

and integration-tests gated to push (merge) events. The integration job

proves connectivity before running tests:


      - name: Verify Apify connection
        run: |
          curl -sf -H "Authorization: Bearer $APIFY_TOKEN" \
            https://api.apify.com/v2/users/me | jq '.data.username'

Full two-job workflow: references/workflows.md (Test Workflow).

Step 3: Create the deploy workflow

Add .github/workflows/apify-deploy.yml — triggered on merges that touch

src/, package.json, or .actor/ (plus workflow_dispatch). It builds,

tests, installs the Apify CLI, apify pushes, then runs a minimal smoke call to

confirm the new build actually starts. Full definition:

references/workflows.md (Deploy Workflow).

Step 4: Write integration tests

Gate live-API tests on the token so they skip cleanly when it is absent:


const SKIP_INTEGRATION = !process.env.APIFY_TOKEN;

describe.skipIf(SKIP_INTEGRATION)('Apify Integration', () => {
  it('should authenticate successfully', async () => {
    const user = await client.user().get();
    expect(user.username).toBeTruthy();
  });
});

The complete suite (auth, live Actor run, create/delete a named dataset with

cleanup) is in references/integration-tests.md.

Step 5: Verify the Actor build

Add a verify-build.yml that docker builds the Actor image and boots it once

to confirm the entry point loads. Optionally add branch-protection rules that

require the CI contexts before merge. Both blocks:

references/workflows.md (Actor Build Verification).

Output

Applying this skill produces committed CI/CD infrastructure in the repository:

  • .github/workflows/apify-test.yml — unit tests on every PR, integration tests

on merge to main.

  • .github/workflows/apify-deploy.ymlapify push + post-deploy smoke test on

merge, plus manual workflow_dispatch.

  • .github/workflows/verify-build.yml — Docker build + entry-point check on PRs.
  • tests/integration/apify.test.ts — token-gated live-API integration suite.
  • Configured GitHub secrets (APIFYTOKEN, optional TEST / _PROD variants)

and, optionally, branch-protection requiring the CI checks to pass.

Once merged, every PR runs unit tests, every merge deploys and smoke-tests the

Actor, and a failed deploy surfaces a ::error:: annotation in the run log.

Error Handling

Issue Cause Solution
APIFY_TOKEN not set Secret not configured gh secret set APIFY_TOKEN
Integration test timeout Slow Actor run Increase timeout, use smaller input
Docker build fails in CI Local-only deps Commit package-lock.json
apify push fails Not logged in Add apify login --token step
Flaky integration tests External service issues Add retries, use test.retry(2)

Examples

Minimal test-on-PR gate — the smallest useful setup is Step 1 (store the

secret) plus the unit-tests job from the test workflow. Every PR then runs

npm ci && npm run build && npm test before it can merge.

Full deploy pipeline — add the deploy workflow so a merge to main that

touches src/** builds, tests, runs apify push, then smoke-tests the new

build:


      - name: Push Actor to Apify
        run: apify push

      - name: Verify deployment
        run: |
          ACTOR_ID=$(jq -r '.name' .actor/actor.json)
          apify actors call $ACTOR_ID \
            --input='{"startUrls":[{"url":"https://example.com"}],"maxItems":1}' \
            --timeout=120

apify-client app (not Actor dev) — for an app that calls Actors rather than

publishing one, mock apify-client in unit tests and gate a real-token

integration job to main. Full workflow:

references/workflows.md (CI Configuration for apify-client Apps).

See references/workflows.md for every full workflow

and references/integration-tests.md for the

complete integration suite.

Resources

Next Steps

For runtime deployment patterns beyond CI wiring — release channels, versioned

Actor builds, and rollback — see the apify-deploy-integration skill in this

pack.

Ready to use apify-pack?