feat(workflows): host the reusable GitHub workflows in this repo - #120
Draft
metalwarrior665 wants to merge 2 commits into
Draft
feat(workflows): host the reusable GitHub workflows in this repo#120metalwarrior665 wants to merge 2 commits into
metalwarrior665 wants to merge 2 commits into
Conversation
Moves the contents of apify-store/github-actions-source here, so a change that spans a CLI feature and the workflow calling it is one PR against one branch instead of two repos with a manual ref dance between them. Consumers pin the `@v1` major tag rather than `@master`, and the setup action installs `apify-test-tools@>=<floor>` (from .github/workflows-min-package-version) instead of `@latest`. That resolves to the same newest stable in the normal case, but makes a workflow's package requirement explicit. The release cadences stay independent, because most changes only touch one side: - workflow-only change: merge, `v1` moves, live, no npm release - package-only change: merge and release when ready, workflows untouched - workflow calling a new CLI feature: raise the floor in the same PR. On merge the `v1` move is held with a warning until that version is on npm, so consumers keep running the previous workflows instead of calling a CLI that doesn't exist yet. A stable release moves the tag; `manual_move_major_tag` is the escape hatch. Also: - run-with-apify-tokens.mjs moves to .github/scripts/, next to the other CI helper and out of eslint's path; the action's `scripts-path` output follows it - pass github.head_ref/base_ref through the environment in pr-build-test, since branch names are attacker-controlled on fork PRs and actionlint gates master here - prettier formatting on the imported files, which husky enforces here Refs in the consumer snippets in the README were still `@new_master` and are updated along with the repo path.
actionlint gates master here and the action wrapper runs shellcheck, which the old repo's CI did not, so this SC2086 came in with the import. Unquoted it would word-split if the runner ever pointed $GITHUB_OUTPUT at a path with spaces.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR introduces a complete set of reusable GitHub workflows and supporting infrastructure that consumer repositories can use for testing, building, and releasing their Actors.
Summary
The package now includes production-ready reusable workflows alongside the CLI, enabling consumer repos to standardize their CI/CD pipelines. These workflows handle platform testing, PR validation, releases, and Claude-powered automated investigation and fixes for failing tests.
Key Changes
Reusable Workflows (
.github/workflows/):pr-build-test.yaml: Runs unit tests and platform tests on pull requestsplatform-tests.yaml: Scheduled platform test runs with Slack reportingpush-build-latest.yaml: Builds and releases Actors on master pushclaude.yaml: Responds to@claudementions to implement fixes via Claude Codeplatform-tests-claude-investigate-and-fix.yaml: Two-phase workflow that uses Claude to investigate failing tests and automatically open issues and PRs_move_major_tag.yaml: Manages the floating@v1tag, only moving it when the required package version is publishedmanual_move_major_tag.yaml: Escape hatch for manual tag managementGitHub Actions (
.github/actions/):checkout-restore-dependencies/action.yaml: Composite action for checkout, Node setup, and dependency caching with npm token isolationHelper Scripts (
.github/scripts/):run-with-apify-tokens.mjs: Securely passes only required Actor tokens to CLI commands, preventing secret leakage tonode_modulesConfiguration:
.github/workflows-min-package-version: Declares the minimum CLI version required by the workflows, gating tag movement until that version is publishedDocumentation:
README.mdwith workflow usage examples, secret handling details, and versioning guidanceCONTRIBUTING.mdto document the workflows as a third component of the packageNotable Implementation Details
Secret Isolation: Secrets are passed only to the steps that need them, never as job-wide environment variables. The
run-with-apify-tokens.mjsscript readsapify-test-tools.config.jsonto determine which Actor tokens to pass, preventing accidental exposure.Versioning Strategy: Consumer repos pin workflows to
@v1(a floating major tag), not@master. The tag only moves when the declared minimum package version is published on npm, preventing workflows from calling unreleased CLI features.Claude Integration: The
platform-tests-claude-investigate-and-fix.yamlworkflow chains investigation and fix phases as job dependencies rather than label triggers, working around GitHub's limitation that scheduled runs cannot trigger other workflows.Backward Compatibility: The
platform-tests.yamlworkflow supports both the deprecatedsubtestinput and the newtest-files-globinput for gradual migration.https://claude.ai/code/session_01SkUZADZ6gzWW4GE6CFMreM