feat(actions): publish setup action for GitHub workflows#28
Conversation
- Deno 2.x project structure with deno.json and task definitions - JSR dependencies: @cliffy/command, @std/assert, @std/testing, @std/yaml, @std/dotenv, @std/fs, @std/path - Full CLI command tree with stubs for all 15 issues - Shared interfaces (ProcessRunner, config types, ExitCode) for parallel work - FakeProcessRunner with recording, pre-programmed responses, and dry-run support - CI pipeline: fmt, lint, typecheck, test, coverage, and cross-platform build - .gitignore for generated and environment-specific files
- Default config values with sensible defaults - Deep merge for 5-layer config resolution (defaults -> base -> profile -> local -> local-profile) - Filesystem discovery (.stackctl, .stackctl.<profile>, .stackctl.local, .stackctl.local.<profile>) - Post-merge validation returning all errors at once - Template generation with inline comments, --detect, --preset, --profile, --force, --dry-run - STACKCTL_PROFILE env var support - 43 config tests + existing 15 = 58 passing - CLI init command wired to real implementation
Port of tools/generate_stacks.py from AniTrend/local-stack to idiomatic Deno TypeScript: - File discovery: walks repo root, finds docker-compose.yml/yaml files with x-stack metadata - Fragment loading: optional swarm.fragment.yml deep-merge per service - Compose deep merge (dict recursive, array replacement, scalar override) - Service transforms: strip compose-only keys (container_name, restart, build), inject logging defaults, rewrite env_file and bind-mount paths to repo-root relative - Named volume collection (external: true), default traefik-public overlay network - YAML output with header comment, --dry-run support - CLI generate command wired to real implementation - 60 compose tests + 58 existing = 118 passing
- composeOverrideMerge: scalars replace, maps merge, sequences append (distinct from fragment merge which replaces arrays) - loadOverrideFile: load YAML override from relative/absolute path - applyOverrides: load and apply chain of override files to base compose - Override integration in generateStacks via GenerateOptions.overrides - 26 tests covering all merge rules, file loading, edge cases - CLI generate command accepts --override flag
- Variable interpolation: ${VAR}, ${VAR-default}, ${VAR:-default}, $VAR, $$
- Variable scope resolution: shell env -> env_file(s) -> service.environment
- Deep interpolation through all string values in compose structures
- Path absolutization for env_file and bind-mount paths
- Strict mode (fail on unresolved) and non-strict mode (leave as-is with warnings)
- CLI pipeline: resolveConfig -> generateStacks -> renderStack -> output
- 49 comprehensive tests covering all interpolation forms and edge cases
Covers config migration, command mapping, profiles, overrides, rollback, troubleshooting, and behavior differences.
- Add composite action at .github/actions/setup-stackctl/action.yml - Support linux-x64, linux-arm64, macos-x64, macos-arm64 - Download from GitHub Releases, verify SHA256, cache in tool cache - Resolve latest version via GitHub API, accept explicit versions - Add PATH integration for subsequent workflow steps - Document CI usage in docs/migration.md Closes #11
- Add RealProcessRunner using Deno.Command with dry-run and signal forwarding - Add Docker CLI integration module (deploy, rm, services, ps, logs, info, swarm) - Add full sync pipeline: config -> discover -> generate -> render -> deploy - Wire CLI commands: up, down, status, logs, doctor, sync - Replace all issue #6 stubs with real implementations - Add 31 new tests (22 docker + 9 sync) all using FakeProcessRunner
- deno.json: add build:* tasks with Deno.compile for 4 targets - .github/workflows/release.yml: build matrix, SHA256 checksums, GitHub Releases - .github/workflows/ci.yml: update build stage to use renamed tasks
wax911
left a comment
wax911
left a comment
There was a problem hiding this comment.
Review notes against #11:
-
The action location does not match the requested consumer contract. The issue asked for a root
action.ymlso consumers can use the repository/action path that was documented. This PR places the action under.github/actions/setup-stackctl, which changes the usage string and weakens the goal of easy consumer setup. -
Input names diverge from the spec. The issue requested
github-token; this implementation usestoken. Either align with the issue or update the docs/issues deliberately. -
Asset naming does not match the release contract. The action downloads raw assets such as
stackctl-linux-x64, while the release issue specified tarballs namedstackctl-v<version>-<target>.tar.gz. -
OS/architecture mapping is incompatible with the agreed release target names. It maps to
linux/x64andmacos/arm64, notx86_64-unknown-linux-gnu,aarch64-apple-darwin, etc. -
sha256sumis not portable to macOS runners. Since the action claims macOS support, checksum verification needs to use a portable mechanism or branch per OS. -
The action depends on
ghbeing available for latest-release resolution. GitHub-hosted runners usually have it, but the action should either document that dependency or usecurlagainst the GitHub API with the provided token.
This cannot be considered compatible with the planned setup-action contract until the release asset contract and action path are aligned.
- Package binaries as stackctl-v<version>-<target>.tar.gz - Include stackctl, README, LICENSE in each tarball - Use portable checksum generation (shasum -a 256) - Add scoped permissions to deno compile commands - Include README/LICENSE copy in build artifacts
wax911
left a comment
wax911
left a comment
There was a problem hiding this comment.
Follow-up review after the push:
Good fixes:
- Input name now matches the spec:
github-token. - Asset naming now matches the release tarball contract:
stackctl-<tag>-<target-triple>.tar.gz. - OS/architecture mapping now uses the agreed target triples.
- Checksum verification now supports both
sha256sumandshasum -a 256. - The action no longer depends on
ghfor latest-release resolution.
Remaining issues:
- The action is still nested at
.github/actions/setup-stackctl/action.yml, while the issue requested a rootaction.ymlso consumers can use the simpler repository action path. If the nested path is intentional, update #11 and all docs to show the actual usage string:
- uses: AniTrend/stackctl/.github/actions/setup-stackctl@v1Otherwise move it to root action.yml and keep the originally planned usage:
- uses: AniTrend/stackctl@v1-
This PR is draft and still targets
mainwith a cumulative diff. Retarget it appropriately before making it ready. -
The latest-release JSON parsing is shell/grep based. It is acceptable for a first pass, but brittle. Consider a tiny Deno helper or safer API parsing later if this starts failing.
The release/action asset contract is now mostly aligned. The main remaining decision is root action vs nested action path.
|
Superseded by #32 (fix-reconstruct-pr28) — setup action already merged. |
1 participant
Closes #11