Pipery Guides on Pipery - Production-grade CI/CD pipelines

Deploying to Cloud Run with Pipery Cloud Run CD

hello@pipery.dev (Pipery) — Thu, 30 Apr 2026 00:00:00 +0000

Once a service is built and tested, the next question is how to deploy it without turning your workflow into another custom shell project. pipery-dev/pipery-cloudrun-cd gives you a reusable Cloud Run deployment step with the same observability story as the CI actions.

Minimal workflow#

name: CD

on:
 push:
 branches: [main]

jobs:
 cd:
 uses: pipery-dev/pipery-cloudrun-cd@v1
 with:
 image_name: ghcr.io/acme/api
 service_name: api
 region: europe-west1
 project_id: acme-platform-prod
 secrets: inherit

What the action does#

The deployment path is straightforward:

push the container image
deploy with gcloud run deploy
migrate traffic
run a status check

Inputs to care about early#

image_name: the image being deployed
image_tag: defaults to the current Git SHA, which is a sensible starting point
service_name: the Cloud Run service to update
region and project_id: define the deployment target
traffic: useful when you want a more careful rollout

Why teams like this pattern#

Cloud Run deployment is simple enough to start casually and tricky enough to drift over time. One team adds traffic handling, another adds status checks, another copies an old auth pattern. A shared action gives you the same deployment shape everywhere, and Pipery’s psh logs make post-deploy debugging much calmer when a rollout does not behave the way you expected.

Source and docs: pipery-cloudrun-cd.

Getting started with Pipery Docker CI

hello@pipery.dev (Pipery) — Thu, 30 Apr 2026 00:00:00 +0000

Container pipelines get messy quickly. pipery-dev/pipery-docker-ci wraps the usual Docker CI sequence into one reusable action, with structured logging built in.

Instead of hand-writing Docker login, build, scan, test, tag, and push steps in every repository, you can move that workflow into a single maintained action call.

Minimal workflow#

name: CI

on:
 push:
 branches: [main]
 pull_request:

jobs:
 ci:
 runs-on: ubuntu-latest
 steps:
 - uses: actions/checkout@v4
 - uses: pipery-dev/pipery-docker-ci@v1
 with:
 image_name: ghcr.io/${{ github.repository }}
 registry_username: ${{ github.actor }}
 registry_password: ${{ secrets.GITHUB_TOKEN }}
 github_token: ${{ secrets.GITHUB_TOKEN }}

What it handles#

The action covers:

Dockerfile linting with Hadolint
SAST with Trivy config scanning
SCA with Trivy image scanning
docker build
container smoke testing
semantic versioning
image tagging
registry push

Inputs teams usually care about first#

dockerfile: useful when the repo has more than one Dockerfile
image_name: the published registry path
build_args: pass image build arguments cleanly
platforms: define target platforms early if multi-arch matters
tests_path: provide the smoke-test command you want run inside the container

Where the observability matters#

Docker builds can fail for reasons that are annoyingly context-heavy: auth, missing files, cache misses, registry problems, and test commands that only fail inside the built image. Because Pipery captures each command as it runs, the failure is not trapped inside a giant opaque shell block. You get replayable, step-level logs in pipery.jsonl.

That is the difference between “the image push step failed somewhere” and “this exact command failed with this exact output.”

Source and docs: pipery-docker-ci.

Getting started with Pipery npm CI

hello@pipery.dev (Pipery) — Thu, 30 Apr 2026 00:00:00 +0000

If your Node.js workflow keeps growing one shell step at a time, pipery-dev/pipery-npm-ci is a clean place to stop and standardize it.

This action is a complete CI workflow for npm and Yarn projects. It covers SAST, dependency scanning, linting, build, test, versioning, packaging, release, and reintegration, while every command is captured in pipery.jsonl through psh.

When to use it#

Use pipery-npm-ci when you want one reusable workflow for JavaScript or TypeScript repositories and you do not want to hand-maintain the usual install, lint, test, package, and publish sequence in every repo.

It is especially helpful when your team wants:

the same CI behavior across several services
predictable release behavior for npm packages
searchable logs instead of long unstructured GitHub output

Minimal workflow#

name: CI

on:
 push:
 branches: [main]
 pull_request:

jobs:
 ci:
 runs-on: ubuntu-latest
 steps:
 - uses: actions/checkout@v4
 - uses: pipery-dev/pipery-npm-ci@v1
 with:
 project_path: .
 npm_token: ${{ secrets.NPM_TOKEN }}
 github_token: ${{ secrets.GITHUB_TOKEN }}

Good first inputs to set#

node_version: pin the runtime your app actually uses
package_manager: set npm or yarn if you do not want auto-detection
tests_path: narrow test execution when a repo needs it
version_bump: control default release behavior

What happens in the pipeline#

The action runs:

SAST with njsscan
SCA with npm audit or yarn audit
lint with ESLint
build with your package manager
tests
semantic versioning
npm pack
npm publish and SHA tagging

That means the repo owner gets a full CI path without rewriting the same workflow skeleton again.

Why Pipery helps here#

Node pipelines often fail in the annoying middle: lockfile drift, a flaky test, a publish auth issue, an unexpected build script change. Pipery logs each executed command and its output in pipery.jsonl, so you can inspect the exact step in the dashboard instead of reconstructing the failure by hand.

Start with the action repo here: pipery-npm-ci.

Getting started with Pipery Python CI

hello@pipery.dev (Pipery) — Thu, 30 Apr 2026 00:00:00 +0000

pipery-dev/pipery-python-ci is the easiest way to give a Python repository a consistent CI pipeline without stitching together half a dozen actions and shell steps.

It is designed for the common Python path: scan the code, audit dependencies, lint, build, test, package, and publish, while producing a structured pipery.jsonl log for the whole run.

When it fits well#

This action is a good match when your repo is using setuptools, Poetry, or uv, and you want one workflow that can grow from pull request validation into package release without being rewritten later.

Minimal workflow#

name: CI

on:
 push:
 branches: [main]
 pull_request:

jobs:
 ci:
 runs-on: ubuntu-latest
 steps:
 - uses: actions/checkout@v4
 - uses: pipery-dev/pipery-python-ci@v1
 with:
 project_path: .
 pypi_token: ${{ secrets.PYPI_TOKEN }}
 github_token: ${{ secrets.GITHUB_TOKEN }}

Inputs worth setting early#

python_version: align CI with the runtime you support
package_manager: choose setuptools, poetry, or uv when you want explicit behavior
tests_path: point pytest at the right subset when your repo needs it
registry: keep the default pypi or adapt when your publish target changes

What the action covers#

The pipeline includes:

SAST with Bandit
SCA with pip-audit or safety
linting with Ruff
build
pytest
semantic versioning
packaging with python -m build
publish with Twine

Why it is useful in practice#

Python repos tend to drift over time. One project uses Poetry, another uses plain setuptools, another quietly changed its test command months ago. Pipery gives you a common CI contract while still exposing the real command history through psh and pipery.jsonl when something fails.

That makes it easier to adopt a standard without losing debuggability.

Source and docs: pipery-python-ci.

Getting started with Pipery Terraform CI

hello@pipery.dev (Pipery) — Thu, 30 Apr 2026 00:00:00 +0000

Infrastructure repositories deserve the same level of repeatability as application repos. pipery-dev/pipery-terraform-ci gives Terraform projects a shared CI pipeline that validates code, checks risk earlier, and leaves behind a structured log you can inspect later.

Minimal workflow#

name: CI

on:
 push:
 branches: [main]
 pull_request:

jobs:
 ci:
 uses: pipery-dev/pipery-terraform-ci@v1
 with:
 project_path: .
 secrets: inherit

What it runs#

The action covers:

tfsec for SAST
dependency scanning
tflint
terraform validate
terraform plan
versioning
release handling

Useful inputs#

terraform_version: pin the CLI version used by the repo
backend_config: provide backend settings cleanly
var_file: point at the right tfvars file
working_directory: useful when the Terraform root is not the repo root

Why this helps teams#

Terraform workflows often grow hidden complexity around backends, environments, validation order, and plan behavior. A shared action makes the happy path repeatable across repos, while Pipery gives you the execution detail to understand a failed validate or plan run without digging through a long shell script.

If your team is trying to standardize infrastructure checks before merge, this is a strong first action to adopt.

Source and docs: pipery-terraform-ci.