Marcus Chukwuoma — marcdomain.dev

vaqum: compress, encrypt, diff and shred files from the command line

Sun, 23 Aug 2026 00:00:00 GMT

I kept reaching for five different tools to do one job: zip or tar to archive, gpg to encrypt, diff to compare, fdupes to find duplicates, shred to delete. They all have different flags, and not all of them exist on every OS.

vaqum puts them in one command that works the same on macOS, Linux and Windows. It's written in Rust, ships as a single binary, and at default settings it's about 5x faster than zip/gzip with output about 12% smaller.

The demo runs through every command below.

What it does

Job	Command
Compress files and folders, optionally encrypted	`vaqum compress`
Decompress `.vaqum`, `.zip` and `.tar.gz` archives	`vaqum decompress`
Inspect an archive, file or folder	`vaqum info`
Compare files, folders or archives	`vaqum diff`
Find (and hardlink) duplicate files	`vaqum dedupe`
Search names and contents	`vaqum search`
Securely delete	`vaqum shred`
Saved defaults and profiles	`vaqum config`
Shell completions	`vaqum completions`

Install

npm i -g @marcdomain/vaqum                    # macOS, Linux, Windows
brew install marcdomain/vaqum/vaqum           # Homebrew
curl -fsSL https://raw.githubusercontent.com/marcdomain/vaqum/main/install.sh | sh   # macOS, Linux
irm https://raw.githubusercontent.com/marcdomain/vaqum/main/install.ps1 | iex        # Windows PowerShell

The npm package pulls in a prebuilt binary for your platform, so there's nothing to compile. Check it worked:

vaqum --version

Compress and decompress

Compress a file. -v shows the stats:

vaqum compress report.txt -v

✔ Compressed 'report.txt' -> 'report.txt.vaqum'
  algorithm:    zstd
  original:     12.61 kB
  compressed:   516 B (24.44x)
  output size:  599 B (21.05x)

By default vaqum uses zstd at level 9. Pick a level from 1 (fastest) to 22 (smallest) with -l, or use --max to switch to xz (LZMA), which is slower and is usually smaller on larger inputs. On a tiny file like this one, zstd actually wins, so it's worth checking with --dry-run first:

vaqum compress report.txt --dry-run          # estimate without writing anything
vaqum compress report.txt -l 19              # higher zstd level
vaqum compress report.txt --max -o report-max.vaqum

Decompress, and check the result matches the original's SHA-256 checksum with --verify:

vaqum decompress report.txt.vaqum -o restored --verify

✔ verified checksum (48a077133b4b4e0541da861082275b948089ef3d6f3c33085a858095d34819c2)
✔ Decompressed -> restored

Folders and bundles

Compress a folder with -r, or several paths into one archive with -o:

vaqum compress project -r
vaqum compress report.txt notes-v1.txt notes-v2.txt -o bundle.vaqum

Skip paths with --exclude (repeatable). End a pattern with / for a folder; a name without / matches at any depth:

vaqum compress webapp -r --exclude node_modules/ --exclude "*.log" -o webapp.vaqum

Or put the patterns in a .vaqumignore file at the folder's root, one per line, like a .gitignore:

node_modules/
dist/
*.log

Deduplication

If a folder has repeated files, --dedup stores each unique file once:

vaqum compress photos -r --dedup -v

  new img1.txt  (12.61 kB)
  dup img2.txt  (12.61 kB)
  new img3.txt  (26 B)
✔ Compressed 'photos' -> 'photos.vaqum'
  algorithm:    zstd + dedup

Compression uses every CPU core by default; limit it with -t <threads>.

Encrypt

Add -e to encrypt with a password, or --key-file to use a file's bytes as the key:

vaqum compress secret.txt -e -o secret.vaqum
vaqum compress secret.txt --key-file key.bin -o secret.vaqum

✔ Compressed and encrypted 'secret.txt' -> 'secret.vaqum'
  encryption:   ChaCha20-Poly1305, Argon2id KDF

The data is encrypted with ChaCha20-Poly1305. The key is derived from your password with Argon2id, and only the salt is stored in the archive, never the key. decompress detects encryption by itself and asks for the password (or takes --key-file).

Open zip and tar.gz files too

decompress and info also read .zip and .tar.gz/.tgz, detected by content rather than file extension, so you don't need another tool to open something a teammate sent:

vaqum info shared.zip
vaqum decompress shared.tar.gz -o shared-restored

This is one-way: vaqum only writes its own format.

Protection from decompression bombs

A small archive can be crafted to expand into terabytes. decompress refuses archives that claim an expansion ratio above 1000:1, or that wouldn't fit on the disk. Change the limit with --max-ratio, or skip the check with --force when you trust the source.

Inspect

info works on archives without fully decompressing them, and on plain files and folders:

vaqum info report.txt.vaqum

report.txt.vaqum
  type:         single file
  name:         report.txt
  algorithm:    zstd
  original:     12.61 kB
  compressed:   516 B (24.44x)
  on disk:      599 B
  checksum:     sha256:48a077133b4b4e0541da861082275b948089ef3d6f3c33085a858095d34819c2
  encrypted:    no

Diff files, folders and archives

diff compares any mix of files, folders and .vaqum archives. That makes it easy to check a backup against the live copy without unpacking it first.

vaqum diff project-backup project -v

comparing 'project-backup' vs 'project':
  1 unchanged, 1 added, 0 removed, 1 modified
  + src/util.rs  (19 B)
  ~ src/main.rs
--- a/src/main.rs
+++ b/src/main.rs
@@ -1,3 +1,3 @@
 fn main() {
-    println!("v1");
+    println!("v2");
 }

Three other ways to view a diff:

vaqum diff a.txt b.txt --html diff.html   # self-contained, offline, side-by-side HTML report
vaqum diff a.txt b.txt --open             # same report, opened in your browser
vaqum diff old/ new/ -e                   # VS Code's split view (code --diff), one tab per changed file

Set VAQUM_DIFF_EDITOR to use another editor. When one side is a .vaqum archive, it's unpacked to a scratch copy first, so edits there don't change the archive.

Find duplicates

dedupe hashes every file in a folder and groups identical ones:

vaqum dedupe photos -v

photos
  files scanned:     3 (25.24 kB)
  duplicate groups:  1 (1 redundant file)
  reclaimable:       12.61 kB

  sha256:48a07713…819c2 (12.61 kB, 2 copies)
    img1.txt
    img2.txt

Add --link to replace duplicates with hardlinks to the first copy. That frees the space without deleting any path. Preview it first with --link --dry-run.

Search

Search file names and contents at once, recursively:

vaqum search TODO app

name     app/TODO-cleanup
content  app/main.rs:2: // TODO: wire up config
content  app/util.rs:1: // TODO: add tests

3 matches (1 file by name, 2 lines of content)

Use -i for case-insensitive, -E for a regular expression, and --names-only or --content-only to narrow it down:

vaqum search 'TODO: \w+' app -E --content-only

Shred

shred overwrites a file before deleting it, so it can't be recovered from the disk. It asks you to confirm first (skip that with -y in scripts):

vaqum shred secret.txt
vaqum shred old-keys/ -r -p 7      # a folder, with 7 overwrite passes
vaqum shred old-keys/ -r --dry-run # list what would be destroyed

⚠  This will permanently and irrecoverably destroy:
    secret.txt (28 B)
✔ Shredded (3 passes, DoD 5220.22-M-style overwrite)
  note: on SSDs, overwrite passes are best-effort (wear-leveling/TRIM) — not forensic-grade.

As the note says, SSDs move data around internally, so overwriting is best-effort there. For data that must never be recoverable on an SSD, use full-disk encryption from the start.

Save your defaults

vaqum config init writes a starter file at ~/.config/vaqum/config.toml (%APPDATA%\vaqum\config.toml on Windows):

[defaults]           # every compress
exclude = ["*.log"]

[compress]           # overrides [defaults] for compress

[profile.release]    # used with --profile release
max = true

vaqum compress dist -r --profile release -o release.vaqum
vaqum config show    # what's in effect
vaqum config path    # where the file is

Flags on the command line always win over the file.

Shell completions

vaqum completions zsh --install    # also bash, fish, powershell, elvish

--install writes the script to your shell's standard completions folder and tells you if one line needs adding to your shell config. It never edits your config itself.

Scripts and CI

Progress bars show on interactive terminals and hide themselves when output is piped. -q hides them explicitly. Combined with -y on shred and --key-file for encryption, every command runs without prompts:

vaqum compress build/ -r -q --key-file "$KEY_FILE" -o "build-$GITHUB_SHA.vaqum"

Publish multi-arch base images to any registry with one GitHub Action

Sat, 01 Aug 2026 00:00:00 GMT

Most teams build on top of public base images like python:3.12-slim or amazon/aws-lambda-python:3.12. Pulling them straight from Docker Hub in every build has drawbacks: rate limits, an outside dependency in every pipeline, and no control over when the base changes. And with Apple Silicon laptops and Graviton servers, you need both amd64 and arm64 images.

multiarch-image-pusher is a GitHub Action that copies a base image into your registry as a multi-arch image, in one step. It can also rebuild it with the latest OS security updates on the way.

One base image in, per-architecture tags and a combined manifest out

What you get

For each run, the action publishes:

one tag per platform: :<tag>-amd64 and :<tag>-arm64 by default;
the combined :<tag>, a manifest list that points to all of them.

When someone runs docker pull my-registry/python-base:3.12-slim, Docker picks the right architecture from the manifest list automatically.

It works with any registry: Amazon ECR, GitHub Container Registry, GitLab Container Registry, Docker Hub, or a generic registry.

Two modes

`update-libraries`	What happens	Use it when
`false` (default)	The image is copied as-is, registry to registry	You want a mirror of the exact upstream image
`true`	Each platform is rebuilt with its OS packages updated, then pushed	You want the latest security fixes without waiting for upstream

When updating, the action detects the package manager in the image (dnf, microdnf, yum, apt-get, apk or zypper), so the same step works for Debian, Ubuntu, Alpine, Amazon Linux, RHEL-family and SUSE images. If it can't find one, it fails with a clear error instead of skipping the update.

Inputs

Input	Required	Default
`base-image`	yes		Image to copy, e.g. `python:3.12-slim`. The runner must be able to pull it
`dest-registry`	yes		Registry hostname, e.g. `ghcr.io`
`dest-image-repo`	yes		Repository in that registry, e.g. `my-org/python-base`
`dest-image-tag`	no	`latest`	Tag to publish
`update-libraries`	no	`false`	`true` to rebuild with OS packages updated
`platforms`	no	`linux/amd64,linux/arm64`	Comma-separated buildx platforms
`buildkit-image`	no		Custom BuildKit image (e.g. a private mirror), used when `update-libraries` is `true`

The action doesn't log in to any registry. Add a login step before it for the destination, and for the source too if it's private. That keeps your credentials in your own workflow.

Example: copy to GHCR as-is

name: Publish base image

on:
  workflow_dispatch:

permissions:
  contents: read
  packages: write

jobs:
  publish:
    runs-on: ubuntu-latest
    steps:
      - name: Log in to GHCR
        run: echo "${{ secrets.GITHUB_TOKEN }}" | docker login ghcr.io --username ${{ github.actor }} --password-stdin

      - uses: marcdomain/multiarch-image-pusher@v1
        with:
          base-image: python:3.12-slim
          dest-registry: ghcr.io
          dest-image-repo: my-org/python-base
          dest-image-tag: '3.12-slim'

This publishes ghcr.io/my-org/python-base:3.12-slim-amd64, :3.12-slim-arm64, and the combined :3.12-slim.

Example: ECR, with OS packages updated, every week

Use GitHub's OIDC to assume an AWS role (no long-lived keys), and a schedule so the image picks up security fixes regularly:

name: Refresh Lambda base image

on:
  schedule:
    - cron: "0 5 * * 1"   # Mondays at 05:00 UTC
  workflow_dispatch:

permissions:
  id-token: write
  contents: read

jobs:
  publish:
    runs-on: ubuntu-latest
    steps:
      - uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::123456789012:role/github-actions-ecr-push
          aws-region: eu-west-1

      - name: Log in to Amazon ECR
        run: aws ecr get-login-password --region eu-west-1 | docker login --username AWS --password-stdin 123456789012.dkr.ecr.eu-west-1.amazonaws.com

      - uses: marcdomain/multiarch-image-pusher@v1
        with:
          base-image: amazon/aws-lambda-python:3.12
          dest-registry: 123456789012.dkr.ecr.eu-west-1.amazonaws.com
          dest-image-repo: aws-lambda
          dest-image-tag: '3.12'
          update-libraries: 'true'

Your Dockerfiles then build FROM 123456789012.dkr.ecr.eu-west-1.amazonaws.com/aws-lambda:3.12.

Example: Docker Hub

jobs:
  publish:
    runs-on: ubuntu-latest
    steps:
      - name: Log in to Docker Hub
        run: echo "${{ secrets.DOCKERHUB_TOKEN }}" | docker login docker.io --username ${{ secrets.DOCKERHUB_USERNAME }} --password-stdin

      - uses: marcdomain/multiarch-image-pusher@v1
        with:
          base-image: alpine:3.20
          dest-registry: docker.io
          dest-image-repo: my-org/alpine-base
          dest-image-tag: '3.20'

Example: more platforms

Add any platform the base image publishes, using buildx syntax. For example, 32-bit ARM for Raspberry Pi-class hardware:

      - uses: marcdomain/multiarch-image-pusher@v1
        with:
          base-image: node:20-bullseye
          dest-registry: registry.gitlab.com
          dest-image-repo: my-group/my-project/node-base
          dest-image-tag: '20-bullseye'
          platforms: linux/amd64,linux/arm64,linux/arm/v7

That adds a :20-bullseye-arm-v7 tag to the manifest.

Example: private source image

    steps:
      - name: Log in to source registry
        run: echo "${{ secrets.SOURCE_REGISTRY_TOKEN }}" | docker login some-private-registry.example.com --username ci --password-stdin

      - name: Log in to destination registry
        run: echo "${{ secrets.DEST_REGISTRY_TOKEN }}" | docker login registry.gitlab.com --username ci --password-stdin

      - uses: marcdomain/multiarch-image-pusher@v1
        with:
          base-image: some-private-registry.example.com/team/base:1.0
          dest-registry: registry.gitlab.com
          dest-image-repo: my-group/my-project/node-base
          dest-image-tag: '1.0'

Example: BuildKit from a private mirror

Rebuilding (update-libraries: 'true') uses BuildKit, which normally comes from Docker Hub. On rate-limited or locked-down runners, point it at your own copy:

      - uses: marcdomain/multiarch-image-pusher@v1
        with:
          base-image: amazon/aws-lambda-python:3.12
          dest-registry: 123456789012.dkr.ecr.eu-west-1.amazonaws.com
          dest-image-repo: aws-lambda
          update-libraries: 'true'
          buildkit-image: 123456789012.dkr.ecr.eu-west-1.amazonaws.com/mirror/buildkit:latest

How it works

Copy as-is (update-libraries: 'false'): for each platform, the action reads the base image's manifest list, finds the entry for that architecture, and copies it to :<tag>-<arch> with docker buildx imagetools create. This happens registry to registry, without pulling layers onto the runner, so it's fast. Then it creates the combined :<tag> from those tags.

A detail that's easy to get wrong: linux/arm64 in buildx syntax doesn't name a variant, but registries record it as arm64/v8 (and linux/arm as arm/v7). The action fills in those defaults so the lookup matches.

Rebuild with updates (update-libraries: 'true'): the action sets up QEMU and buildx, writes a small Dockerfile per platform that runs the detected package manager's update command (for example apt-get update && apt-get upgrade -y or apk upgrade), cleans the package cache, builds and pushes each platform, then creates and pushes the manifest list with docker manifest. For Amazon Linux, it also points the release version at latest so updates come from the newest repository.

Check the result

docker buildx imagetools inspect ghcr.io/my-org/python-base:3.12-slim

You should see one entry per platform, for example linux/amd64 and linux/arm64.

Good to know

The base image must already publish every platform you ask for. If one is missing, the copy fails with No manifest entry for platform … found in ….
Rebuilding under QEMU emulation is slower than copying, especially for non-native platforms. Copying is the default for that reason.
Pin the action to a release tag (@v1, or a specific one like @v1.1.3) in production workflows.

IGNOREIT: configure your ignore list once, and it's applied in every repo

Thu, 23 Dec 2021 00:00:00 GMT

Every project ends up with files that should never be committed: .env files and private keys, but also node_modules, build output, test coverage, Terraform state, editor and OS files. Each new repo needs the same .gitignore lines again, and it only takes one forgotten line and one git add . for them to land in git.

For build output that's just noise in your history. For secrets it's worse: deleting the file afterwards doesn't help, because it stays in git history, every clone already has it, and bots scan public repositories for keys within minutes. The only real fix then is to rotate every secret in it.

IGNOREIT removes that step. You configure your list of files and folders once, in VS Code. From then on, in every project you open, any file or folder on that list is added to .gitignore as soon as it shows up, before you get the chance to commit it.

It's free, open source, and has been on the VS Code Marketplace since 2020, with 1,800+ installs.

In short: install it, then list what you never want in git, for example "ignoreit.array": [".env", "*.pem", "node_modules", "coverage"]. From then on, those files and folders are always ignored, in every repo you open.

The whole flow in VS Code: set your list once, then .env, node_modules, a new key and coverage are ignored as they appear, .env.example stays in sync, and git status shows no secrets. Every file and notification matches what the extension produces.

What it does

Applies your list everywhere. One list in your VS Code settings covers every project. When a file or folder from it exists in the project, it's added to .gitignore. No .gitignore yet? One is created.
Keeps watching. Files that appear later, like a coverage folder after your first test run or a key you download, are added as soon as they show up.
Leaves your own entries alone. New lines are appended at the end. Anything you wrote by hand stays where it is, and an entry that's already covered isn't added again.
Understands wildcards. *.pem covers server.pem and client.pem. Dotfiles like .env match too.
Keeps .env.example in sync (optional). It copies the variable names from .env into .env.example, without the values, so teammates know what to set.
Tells you what it did. A notification such as .env, *.pem added to .gitignore appears each time it changes the file.

Install

In VS Code, open the Extensions view (Cmd/Ctrl + Shift + X), search for ignoreit, and click Install. Or from a terminal:

code --install-extension marcdomain.ignoreit

It needs nothing else. It works in any folder that is a git repository, meaning the folder you open has a .git folder at its root.

Choose what to ignore

Open Settings (Cmd/Ctrl + ,) and search for ignoreit:

The two settings: the list of files and folders, and the .env.example option

Click Add Item to add an entry. Or open settings.json (Command Palette → Preferences: Open User Settings (JSON)) and edit the list directly:

{
  "ignoreit.array": [".env", "*.pem", "*.key", "node_modules", "coverage"]
}

The default is [".env", "*.pem"].

Put it in your User settings to protect every project you open.
Put it in a project's .vscode/settings.json to use a different list for that project.

After changing the list, run Developer: Reload Window so the extension picks it up.

Starter lists

A few lists worth copying. Add only what you never want committed:

Stack	Entries
Any project	`.env`, `.env.local`, `.pem`, `.key`, `*.p12`
Node.js	`node_modules`, `coverage`, `.next`, `dist`
Python	`.venv`, `venv`, `__pycache__`, `.pytest_cache`
Terraform	`.terraform`, `.tfstate`, `.tfstate.backup`
Editors and OS	`.DS_Store`, `.idea`

Folders are written without a trailing slash: node_modules, not node_modules/.

When it runs

Automatically, whenever files in the workspace change, for example when you save. Changes to .gitignore and .env.example themselves don't trigger it, so it never loops.
On demand, with the command ignoreit: auto ignore files and folders from the Command Palette, or the shortcut Cmd + Shift + I (macOS) / Ctrl + Shift + I (Windows, Linux).

A walk-through

Here's a new project with a .git folder and no .gitignore yet:

my-api/
├── .git/
├── .env
├── server.pem
├── node_modules/
├── package.json
└── src/

With this list:

{ "ignoreit.array": [".env", "*.pem", "node_modules", "coverage"] }

IGNOREIT shows .env, *.pem, node_modules added to .gitignore and creates:

.env
*.pem
node_modules

coverage isn't added yet, because there's no coverage folder. Run your tests, and as soon as coverage/ appears you'll see coverage added to .gitignore:

.env
*.pem
node_modules
coverage

Run it again with nothing new, and nothing happens. It never adds the same entry twice.

With an existing .gitignore

Your file is kept as it is, and only what's missing is appended. If the project already has:

# mine
dist/
.env*

and your list is [".env", "*.pem"] with a .env and a server.pem in the project, only *.pem is added. .env is skipped because .env* already covers it.

Keep .env.example in sync

.env.example is the file you do commit. It lists the variables the app needs, without their values, so a new teammate can copy it to .env and fill it in. Keeping it up to date by hand is easy to forget. Turn on the second setting:

{
  "ignoreit.array": [".env", "*.pem"],
  "ignoreit.updateEnvExample": true
}

It only runs when .env is in ignoreit.array and the project has a .env file.

When there's no .env.example, it creates one from .env with every value removed. Comments and blank lines are kept:

# .env
# Database
DATABASE_URL=postgres://admin:s3cret@localhost:5432/app
REDIS_URL=redis://localhost:6379

STRIPE_KEY=sk_live_51H…

# .env.example (generated)
# Database
DATABASE_URL=
REDIS_URL=

STRIPE_KEY=

When .env.example already exists, it only appends variables that are new. Your comments, ordering and example values are kept:

# .env.example, before
# documented
A=example-a

Add B and C to .env, save, and it becomes:

# .env.example, after
# documented
A=example-a
B=
C=

It never removes a variable from .env.example, so if you delete one from .env, remove it from the example yourself.

Good to know

It looks at the top level of the project. A server.pem in the project root is detected; one inside certs/ isn't. The *.pem line it writes still ignores .pem files at any depth, because that's how .gitignore patterns work.
Write folders without a trailing slash in the list (node_modules). If your .gitignore already says node_modules/, IGNOREIT may add a plain node_modules line too. Both mean the same thing to git, so it's harmless.
Be careful with .env*. It catches .env.local and .env.production, but in .gitignore it also hides .env.example, which you want to commit. List the exact files instead (.env, .env.local), or add !.env.example to your .gitignore after the .env* line.
Multi-root workspaces: it works on the first folder of the workspace.
It doesn't scan file contents. It matches names. Hard-coded secrets in source files need a secret scanner, such as GitHub's push protection.

Already committed a secret?

.gitignore only stops untracked files from being added. If a file is already in git, ignoring it does nothing. To fix it:

Rotate the secret first. Assume it's compromised: change the password, revoke the key.

Stop tracking the file, keeping it on disk:

git rm --cached .env
git commit -m "Stop tracking .env"

If the repository is shared or public, the file is still in history. Remove it with a tool like git filter-repo, then force-push and ask everyone to re-clone. This is why rotating comes first.

Settings

Setting	Default
`ignoreit.array`	`[".env", "*.pem"]`	Files, folders and wildcard patterns to always ignore
`ignoreit.updateEnvExample`	`false`	Keep `.env.example` in sync with the variable names in `.env`

Command	Shortcut
ignoreit: auto ignore files and folders	Cmd + Shift + I (macOS), Ctrl + Shift + I (Windows, Linux)

Version history

Date
March 2020	First release on the VS Code Marketplace
January 2023	Wildcard patterns such as `*.pem`
September 2025	Full glob matching, and existing `.gitignore` patterns respected (7.5)
December 2025	Existing `.env.example` files are kept; only new variables are appended
August 2026	7.6.2: security update to a development dependency

How to generate Cucumber test reports

Sat, 22 Feb 2020 00:00:00 GMT

This follows on from end-to-end test automation with Selenium and Cucumber. Terminal output is fine while you write tests, but when a run fails in CI, or you want to show results to someone else, you need a report: every feature, scenario and step, with timings, errors and screenshots.

Cucumber.js produces reports through formatters. You can use several at once, each writing to its own file.

Option 1: the built-in HTML report

Modern Cucumber (@cucumber/cucumber) has an HTML formatter built in. Nothing to install:

npx cucumber-js --format html:reports/cucumber-report.html

Or set it once in cucumber.js, alongside the console output:

// cucumber.js
module.exports = {
  default: {
    paths: ["features/**/*.feature"],
    require: ["features/**/*.js"],
    format: ["progress-bar", "html:reports/cucumber-report.html"],
  },
}

The result is a single, self-contained HTML file you can open anywhere. It has a search box, filters by status, and shows attachments, such as the screenshots our After hook adds when a step fails:

// features/support/hooks.js
const { After, Status } = require("@cucumber/cucumber")

After(async function ({ result }) {
  if (result?.status === Status.FAILED && this.driver) {
    const png = await this.driver.takeScreenshot()
    this.attach(Buffer.from(png, "base64"), "image/png")
  }
  await this.driver?.quit()
})

For most projects, this is all you need.

Option 2: a Bootstrap-style report from JSON

If you prefer a dashboard with charts and custom metadata, write a JSON report and convert it with cucumber-html-reporter.

npm install --save-dev cucumber-html-reporter

Add a JSON formatter:

// cucumber.js
module.exports = {
  default: {
    paths: ["features/**/*.feature"],
    require: ["features/**/*.js"],
    format: ["progress-bar", "json:reports/cucumber-report.json"],
  },
}

Then a small script that turns the JSON into HTML:

// scripts/report.js
const reporter = require("cucumber-html-reporter")

reporter.generate({
  theme: "bootstrap",
  jsonFile: "reports/cucumber-report.json",
  output: "reports/cucumber-report.html",
  reportSuiteAsScenarios: true,
  scenarioTimestamp: true,
  launchReport: !process.env.CI, // open it in a browser locally, not in CI
  metadata: {
    "App version": process.env.APP_VERSION || "local",
    Browser: "Chrome",
    Platform: process.platform,
    Executed: process.env.CI ? "CI" : "Local",
  },
})

{
  "scripts": {
    "test:e2e": "cucumber-js",
    "test:e2e:report": "node scripts/report.js"
  }
}

Run the tests, then build the report. Use ; (or a posttest script) so the report is generated even when tests fail:

npm run test:e2e; npm run test:e2e:report

Screenshots attached in hooks are embedded in the JSON, so they show up here too.

Option 3: publish reports from CI

Keep the report from every CI run as a downloadable artifact:

# .github/workflows/e2e.yml (steps)
- run: npm run test:e2e:headless
- run: npm run test:e2e:report
  if: always()
- uses: actions/upload-artifact@v4
  if: always()
  with:
    name: cucumber-report
    path: reports/

if: always() makes both steps run after a failure, which is exactly when you want the report. Download it from the run's Summary page under Artifacts.

Keep reports out of git

Reports are build output. Add the folder to .gitignore:

reports/

Which one to pick

	Built-in HTML	cucumber-html-reporter
Install	Nothing	One dev dependency
Steps	One formatter	JSON formatter + a script
Screenshots	Yes	Yes
Charts and custom metadata	No	Yes

Start with the built-in HTML formatter. Add the JSON route when you need charts or extra metadata for stakeholders.

End-to-end test automation with Selenium and Cucumber

Sat, 22 Feb 2020 00:00:00 GMT

End-to-end (E2E) tests drive your application the way a user would: open a browser, click, type, and check what appears. They catch the bugs unit tests can't, like a broken form, a wrong redirect or a missing button.

In this guide we'll use two tools:

selenium-webdriver to control a real browser (Chrome here, but Firefox, Edge and Safari work too).
Cucumber to write the scenarios in plain English (Gherkin), so product owners and testers can read them too.

By the end you'll have a project that runs locally with a visible browser, runs headless in CI, and saves a screenshot of every failing step.

What you need

Node.js 22 or newer
Google Chrome

You don't need to install ChromeDriver yourself. Since version 4.6, Selenium ships with Selenium Manager, which finds your browser and downloads the matching driver on first run.

Set up the project

mkdir e2e && cd e2e
npm init -y
npm install --save-dev @cucumber/cucumber selenium-webdriver

The Cucumber package used to be called cucumber. It's now @cucumber/cucumber; if you're updating an old project, swap the package and the require lines.

Create this layout:

e2e/
├── cucumber.js
├── package.json
└── features/
    ├── web-form.feature
    ├── step_definitions/
    │   └── web-form.steps.js
    └── support/
        ├── world.js
        └── hooks.js

Configure Cucumber

cucumber.js holds the default options, so npx cucumber-js needs no flags:

// cucumber.js
module.exports = {
  default: {
    paths: ["features/**/*.feature"],
    require: ["features/**/*.js"],
    format: ["progress-bar", "html:reports/cucumber-report.html"],
  },
}

Add scripts to package.json:

{
  "scripts": {
    "test:e2e": "cucumber-js",
    "test:e2e:headless": "HEADLESS=1 cucumber-js"
  }
}

Write the scenarios

We'll test Selenium's own demo form, a stable page made for exactly this. Testing against a real search engine tends to break: they show consent pages and block automated browsers.

# features/web-form.feature
Feature: Web form
  As a visitor
  I want to submit the web form
  So that my input is received

  Background:
    Given I open the web form

  Scenario: Submitting the form shows a confirmation
    When I type "Hello Selenium" into the text input
    And I submit the form
    Then I should see the message "Received!"

  Scenario Outline: The form accepts different inputs
    When I type "<text>" into the text input
    And I submit the form
    Then I should see the message "Received!"

    Examples:
      | text          |
      | short         |
      | with spaces   |
      | 12345         |

Background runs before every scenario, and a Scenario Outline runs once per row of Examples.

Create a browser for each scenario

Cucumber gives every scenario a fresh World object (this inside steps and hooks). We'll put the browser on it, so each scenario starts clean.

// features/support/world.js
const { setWorldConstructor, setDefaultTimeout, World } = require("@cucumber/cucumber")
const { Builder, Browser } = require("selenium-webdriver")
const chrome = require("selenium-webdriver/chrome")

setDefaultTimeout(30 * 1000)

class BrowserWorld extends World {
  async openBrowser() {
    const options = new chrome.Options()
    options.addArguments("--window-size=1366,900")
    if (process.env.HEADLESS) options.addArguments("--headless=new")

    this.driver = await new Builder().forBrowser(Browser.CHROME).setChromeOptions(options).build()
  }
}

setWorldConstructor(BrowserWorld)

The hooks open the browser before each scenario, and close it afterwards. If a scenario fails, they attach a screenshot to the report first.

// features/support/hooks.js
const { Before, After, Status } = require("@cucumber/cucumber")

Before(async function () {
  await this.openBrowser()
})

After(async function ({ result }) {
  if (result?.status === Status.FAILED && this.driver) {
    const png = await this.driver.takeScreenshot()
    this.attach(Buffer.from(png, "base64"), "image/png")
  }
  await this.driver?.quit()
})

Write the steps

Each Gherkin line maps to a step definition. {string} captures a quoted value from the scenario.

// features/step_definitions/web-form.steps.js
const { Given, When, Then } = require("@cucumber/cucumber")
const { By, until } = require("selenium-webdriver")
const assert = require("node:assert/strict")

const FORM_URL = "https://www.selenium.dev/selenium/web/web-form.html"

Given("I open the web form", async function () {
  await this.driver.get(FORM_URL)
  assert.equal(await this.driver.getTitle(), "Web form")
})

When("I type {string} into the text input", async function (text) {
  const input = await this.driver.findElement(By.id("my-text-id"))
  await input.clear()
  await input.sendKeys(text)
})

When("I submit the form", async function () {
  await this.driver.findElement(By.css("button[type='submit']")).click()
})

Then("I should see the message {string}", async function (expected) {
  const message = await this.driver.wait(until.elementLocated(By.id("message")), 5000)
  assert.equal(await message.getText(), expected)
})

A few habits that keep E2E tests reliable:

Wait for things, don't sleep. driver.wait(until.elementLocated(...)) returns as soon as the element exists. A fixed sleep is either too short (flaky) or too long (slow).
Prefer stable locators. IDs and data-testid attributes survive redesigns; long CSS paths and XPath tied to layout don't.
One browser per scenario. Shared browsers leak cookies and state between tests.

Run the tests

npm run test:e2e            # opens Chrome so you can watch
npm run test:e2e:headless   # no window, as in CI

4 scenarios (4 passed)
24 steps (24 passed)

Open reports/cucumber-report.html in a browser to see every scenario and step, with screenshots attached to any failures. To learn more about reports, read how to generate Cucumber test reports.

Run them in CI

GitHub's ubuntu-latest runners come with Chrome installed, and Selenium Manager fetches the driver, so the workflow is short:

# .github/workflows/e2e.yml
name: e2e
on: [push, pull_request]

jobs:
  e2e:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
          cache: npm
      - run: npm ci
      - run: npm run test:e2e:headless
      - uses: actions/upload-artifact@v4
        if: always()
        with:
          name: cucumber-report
          path: reports/

if: always() uploads the report even when tests fail, which is when you need it most.

Growing the suite

For a larger application, move locators and actions into page objects (one class per page), so steps read like await formPage.submit("Hello") and a changed selector is fixed in one place. I wrote about structuring bigger suites in two parts: part one and part two.

Configuration and change management with Packer and Ansible

Sat, 15 Feb 2020 00:00:00 GMT

In this guide we'll automate the setup of a server end to end. Packer builds an Amazon Machine Image (AMI), Ansible configures it (Node.js, an Express app, NGINX as a reverse proxy), and we launch an EC2 instance from the result. Every server you launch from that image is identical, and changing the setup means changing code, not clicking around a console.

Configuration and change management

Configuration vs. change management

They're related, but not the same:

Configuration management keeps a known, versioned record of how your systems are set up: packages and their versions, config files, users, network addresses. If a server dies, you can rebuild it exactly.
Change management is how changes to that setup are proposed, reviewed, applied and rolled back.

Keeping both in code (here, a Packer template and an Ansible playbook in git) gives you:

Reliability. The setup is written down, not in someone's head. Failures are easier to recover from because rebuilding is a command.
A history. Git shows what changed, when and why, which makes the next decision easier.
Lower cost and risk. Fewer one-off servers, less drift, and reviewable changes.

The tools

Packer builds machine images from a template. It starts a temporary instance, runs your provisioners on it, saves the disk as an image, and cleans up.
Ansible describes the desired state of a machine in YAML playbooks and applies it over SSH. Its modules are idempotent: running a playbook twice gives the same result.

Baking the configuration into an image (instead of configuring servers after they boot) is often called immutable infrastructure: to change a server, you build a new image and replace it.

What you need

An AWS account and credentials that can create EC2 instances, AMIs, key pairs and security groups
Packer 1.10 or newer
Ansible on your machine (Packer's ansible provisioner runs it from your machine over SSH)

On macOS:

brew tap hashicorp/tap
brew install hashicorp/tap/packer
brew install ansible

On Windows, Packer is available with choco install packer. Ansible's control node doesn't run on Windows directly; use WSL.

AWS credentials

Packer uses the standard AWS credential chain, so whatever works for the AWS CLI works here: an SSO profile, ~/.aws/credentials, or environment variables.

aws configure sso          # or: aws configure
export AWS_PROFILE=my-profile
export AWS_REGION=eu-west-1

If you prefer a .env file, keep it out of git. If you use VS Code, IGNOREIT adds .env to .gitignore for you and can keep a .env.example in sync.

Project layout

packer-ansible/
├── packer/
│   └── express-app.pkr.hcl
└── ansible/
    ├── playbook.yml
    └── templates/
        ├── express-app.service.j2
        └── nginx-site.conf.j2

The Packer template

Packer templates are written in HCL2 (the old JSON format is deprecated). Plugins are separate from Packer, and the required_plugins block lets packer init install them.

# packer/express-app.pkr.hcl
packer {
  required_plugins {
    amazon = {
      source  = "github.com/hashicorp/amazon"
      version = ">= 1.3.0"
    }
    ansible = {
      source  = "github.com/hashicorp/ansible"
      version = ">= 1.1.0"
    }
  }
}

variable "region" {
  type    = string
  default = "eu-west-1"
}

variable "instance_type" {
  type    = string
  default = "t3.micro"
}

locals {
  timestamp = formatdate("YYYYMMDD-hhmmss", timestamp())
}

source "amazon-ebs" "ubuntu" {
  region        = var.region
  instance_type = var.instance_type
  ssh_username  = "ubuntu"
  ami_name      = "express-app-${local.timestamp}"

  # Latest Ubuntu 24.04 LTS image published by Canonical
  source_ami_filter {
    filters = {
      name                = "ubuntu/images/hvm-ssd-gp3/ubuntu-noble-24.04-amd64-server-*"
      root-device-type    = "ebs"
      virtualization-type = "hvm"
    }
    owners      = ["099720109477"] # Canonical
    most_recent = true
  }

  tags = {
    Name    = "express-app"
    BuiltBy = "packer"
  }
}

build {
  sources = ["source.amazon-ebs.ubuntu"]

  provisioner "ansible" {
    playbook_file = "../ansible/playbook.yml"
    user          = "ubuntu"
    use_proxy     = false
  }
}

A few things to note:

The AMI name includes a timestamp, because AMI names must be unique. Every build creates a new image instead of failing on the second run.
owners = ["099720109477"] is Canonical's account, so you only ever get official Ubuntu images.
use_proxy = false lets Ansible connect straight to the build instance over SSH, which avoids problems with the plugin's local proxy on newer OpenSSH versions.

The Ansible playbook

The playbook installs Node.js 22 from NodeSource, deploys a small Express app (it listens on port 3000), runs it as a systemd service, and puts NGINX in front on port 80.

# ansible/playbook.yml
- name: Configure the Express app server
  hosts: all
  become: true
  vars:
    app_name: express-app
    app_user: ubuntu
    app_dir: /opt/express-app
    app_repo: https://github.com/marcdomain/basic-express-app.git
    app_port: 3000
    node_major: 22

  tasks:
    - name: Install base packages
      ansible.builtin.apt:
        # acl lets Ansible run tasks as the app user; python3-debian is needed by deb822_repository
        name: [acl, ca-certificates, curl, git, nginx, python3-debian]
        state: present
        update_cache: true

    - name: Add the NodeSource repository and its signing key
      ansible.builtin.deb822_repository:
        name: nodesource
        types: deb
        uris: "https://deb.nodesource.com/node_{{ node_major }}.x"
        suites: nodistro
        components: main
        signed_by: https://deb.nodesource.com/gpgkey/nodesource-repo.gpg.key

    - name: Install Node.js
      ansible.builtin.apt:
        name: nodejs
        state: present
        update_cache: true

    - name: Clone the app
      ansible.builtin.git:
        repo: "{{ app_repo }}"
        dest: "{{ app_dir }}"
        version: master

    - name: Give the app user the app folder
      ansible.builtin.file:
        path: "{{ app_dir }}"
        owner: "{{ app_user }}"
        group: "{{ app_user }}"
        recurse: true

    - name: Install production dependencies
      ansible.builtin.command: npm install --omit=dev
      args:
        chdir: "{{ app_dir }}"
      become_user: "{{ app_user }}"
      changed_when: true

    - name: Install the systemd service
      ansible.builtin.template:
        src: templates/express-app.service.j2
        dest: /etc/systemd/system/{{ app_name }}.service
        mode: "0644"
      notify: Restart app

    - name: Start the app on boot
      ansible.builtin.systemd_service:
        name: "{{ app_name }}"
        enabled: true
        state: started
        daemon_reload: true

    - name: Remove the default NGINX site
      ansible.builtin.file:
        path: /etc/nginx/sites-enabled/default
        state: absent
      notify: Reload nginx

    - name: Add the reverse proxy site
      ansible.builtin.template:
        src: templates/nginx-site.conf.j2
        dest: /etc/nginx/sites-available/{{ app_name }}
        mode: "0644"
      notify: Reload nginx

    - name: Enable the reverse proxy site
      ansible.builtin.file:
        src: /etc/nginx/sites-available/{{ app_name }}
        dest: /etc/nginx/sites-enabled/{{ app_name }}
        state: link
      notify: Reload nginx

    - name: Start NGINX on boot
      ansible.builtin.systemd_service:
        name: nginx
        enabled: true
        state: started

  handlers:
    - name: Restart app
      ansible.builtin.systemd_service:
        name: "{{ app_name }}"
        state: restarted
        daemon_reload: true

    - name: Reload nginx
      ansible.builtin.systemd_service:
        name: nginx
        state: reloaded

The systemd unit keeps the app running and restarts it if it crashes:

# ansible/templates/express-app.service.j2
[Unit]
Description={{ app_name }}
After=network.target

[Service]
User={{ app_user }}
WorkingDirectory={{ app_dir }}
Environment=NODE_ENV=production
ExecStart=/usr/bin/node app.js
Restart=always
RestartSec=3

[Install]
WantedBy=multi-user.target

And the NGINX site forwards port 80 to the app:

# ansible/templates/nginx-site.conf.j2
server {
    listen 80 default_server;
    server_name _;

    location / {
        proxy_pass http://127.0.0.1:{{ app_port }};
        proxy_http_version 1.1;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

Why these choices:

Fully qualified module names (ansible.builtin.apt) are the current Ansible style and avoid clashes with collections.
Templates instead of echo in shell tasks make config files reviewable, and Ansible only changes them when their content changes.
Handlers restart or reload a service only when something it depends on actually changed.
systemd instead of a process manager means one less tool to install: the OS starts the app on boot and restarts it on failure.

Build the image

cd packer
packer init .
packer fmt .
packer validate .
packer build .

init installs the Amazon and Ansible plugins.
fmt and validate catch formatting and syntax errors before you spend money on an instance.
build starts a temporary EC2 instance, runs the playbook on it, creates the AMI, and terminates the instance.

Override a variable at build time with -var:

packer build -var "region=us-east-1" -var "instance_type=t3.small" .

At the end, Packer prints the new AMI ID:

==> Builds finished. The artifacts of successful builds are:
--> amazon-ebs.ubuntu: AMIs were created:
eu-west-1: ami-0123456789abcdef0

Launch an instance from the image

With the AWS CLI

Create a security group that allows HTTP from anywhere and SSH only from your IP:

MY_IP=$(curl -s https://checkip.amazonaws.com)

SG_ID=$(aws ec2 create-security-group \
  --group-name express-app \
  --description "HTTP from anywhere, SSH from my IP" \
  --query GroupId --output text)

aws ec2 authorize-security-group-ingress --group-id "$SG_ID" --protocol tcp --port 80 --cidr 0.0.0.0/0
aws ec2 authorize-security-group-ingress --group-id "$SG_ID" --protocol tcp --port 22 --cidr "$MY_IP/32"

Then launch an instance from your AMI (replace the AMI ID and key pair name):

INSTANCE_ID=$(aws ec2 run-instances \
  --image-id ami-0123456789abcdef0 \
  --instance-type t3.micro \
  --key-name my-key \
  --security-group-ids "$SG_ID" \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=express-app}]' \
  --query 'Instances[0].InstanceId' --output text)

aws ec2 wait instance-running --instance-ids "$INSTANCE_ID"

aws ec2 describe-instances --instance-ids "$INSTANCE_ID" \
  --query 'Reservations[0].Instances[0].PublicIpAddress' --output text

Open http://<public-ip> in your browser and you'll see It works! 🥂.

With the console

Open the EC2 console in the region you built in.
Go to Images → AMIs, select your express-app-… image, and choose Launch instance from AMI.
Pick an instance type (t3.micro is fine) and a key pair.
Under Network settings, allow HTTP from anywhere and SSH from My IP.
Launch, then open the instance's Public IPv4 address in your browser.

Note that the security group opens port 80 (NGINX), not 3000. The app only listens on localhost; NGINX is the only way in.

Making a change

This is where the setup pays off. To change the server (a new Node.js version, an NGINX header, a new app release):

Change the playbook or template, and open a pull request so the change is reviewed.
Run packer build . to bake a new AMI.
Launch new instances from it (or update your launch template / Auto Scaling group), check them, then terminate the old ones.

Rolling back is launching from the previous AMI.

Clean up

AMIs keep a snapshot, which costs money while it exists. When you're done:

aws ec2 terminate-instances --instance-ids "$INSTANCE_ID"
aws ec2 deregister-image --image-id ami-0123456789abcdef0
# then delete the AMI's snapshot under EC2 → Snapshots

The original code for this guide is on GitHub.

How to SSH into a CircleCI build container

Thu, 23 Jan 2020 00:00:00 GMT

source: CircleCI docs

When a CircleCI job runs, it gets a fresh container or VM (Linux, macOS, Windows…) that acts as your machine for the length of the job. Your code is checked out, dependencies installed, tests run, and artifacts built and deployed, one step after another. Each step's output feeds the next, which is what makes it a pipeline.

When a step fails and the logs don't say why, the fastest fix is often to get inside that exact environment and look around. CircleCI lets you do that by rerunning the job with SSH.

Why SSH into a build

Reproduce a failure in the exact environment it happened in, and try fixes live.
Check what's installed: tool versions, packages, and whether a cache was restored.
Find files: where something was written, or why a path doesn't exist.
Inspect environment variables without printing them in your build logs.

Check resources when a job is slow or runs out of memory:

cat /proc/meminfo    # memory (Linux)
nproc                # CPU cores
df -h                # disk

A note on environment variables: you could add a step that runs printenv, but then every value ends up in the build logs, visible to anyone who can see the project.

Don't do this: it prints your secrets to the logs

Reading them over SSH keeps them out of the logs. But it also means anyone who can rerun a job with SSH can read your project's secrets, so treat that ability as sensitive.

Step 1: set up an SSH key

CircleCI authorises the SSH session with the keys on your GitHub (or Bitbucket) account. If you already push to GitHub over SSH, you can skip to step 2.

Check for an existing key:

ls ~/.ssh/id_ed25519.pub ~/.ssh/id_rsa.pub 2>/dev/null

If there's none, create one. Ed25519 keys are shorter and faster than RSA, and are what GitHub recommends:

ssh-keygen -t ed25519 -C "you@example.com"

Press Enter to accept the default file (~/.ssh/id_ed25519), and choose a passphrase.

Start the SSH agent and add the key. On macOS, --apple-use-keychain saves the passphrase in your Keychain (it replaces the old -K flag):

eval "$(ssh-agent -s)"
ssh-add --apple-use-keychain ~/.ssh/id_ed25519   # macOS
ssh-add ~/.ssh/id_ed25519                        # Linux

Copy the public key:

pbcopy < ~/.ssh/id_ed25519.pub                   # macOS
cat ~/.ssh/id_ed25519.pub                        # anywhere: copy the output

Add it to GitHub under Settings → SSH and GPG keys → New SSH key, and check it works:

ssh -T git@github.com

Step 2: rerun the job with SSH

Open the failed (or any) job in CircleCI, open the Rerun menu at the top right, and choose Rerun job with SSH.

Rerun job with SSH (older CircleCI interface; the option is in the same place today)

The job runs again with an extra Enable SSH step. Expand it to find the connection command:

The Enable SSH step shows the host and port

You can now SSH into this box if your SSH public key is added:
    $ ssh -p 54782 3.80.12.34

Step 3: connect

Run the command from your terminal:

ssh -p 54782 3.80.12.34

If you have several keys and the connection is refused, point SSH at the right one:

ssh -i ~/.ssh/id_ed25519 -p 54782 3.80.12.34

Step 4: debug

You're now in the same environment as the job, after its steps have run. Some useful starting points:

cd ~/project            # the default working directory for checked-out code
ls -la                  # did checkout and the build produce what you expect?
printenv | sort         # environment variables (stays in your terminal, not the logs)
node --version          # tool versions
cat "$BASH_ENV"         # variables exported by earlier steps

Then rerun the command from the failing step and try fixes. Anything you change only lives in this box, so copy working fixes back into your code or .circleci/config.yml.

Step 5: end the session

The SSH job keeps running until you disconnect and it times out, and it uses credits while it runs. When you're done:

exit

Then cancel the job in the CircleCI UI so it doesn't keep running. See CircleCI's debugging with SSH docs for the current time limits.

Troubleshooting

Problem	Fix
`Permission denied (publickey)`	The key on this machine isn't on the GitHub/Bitbucket account you use with CircleCI. Check `ssh -T git@github.com`, or pass the key with `-i`
`Too many authentication failures`	SSH tried other keys first. Use `ssh -i <key> -o IdentitiesOnly=yes -p <port> <ip>`
No Rerun job with SSH option	You need permission to rerun jobs on the project; ask an admin of your CircleCI organisation
The command from a step isn't found	You may be in a different shell. Check `echo $SHELL` and the `shell:` in your config

Marcus Chukwuoma — marcdomain.dev

vaqum: compress, encrypt, diff and shred files from the command line

What it does

Install

Compress and decompress

Folders and bundles

Deduplication

Encrypt

Open zip and tar.gz files too

Protection from decompression bombs

Inspect

Diff files, folders and archives

Find duplicates

Search

Shred

Save your defaults

Shell completions

Scripts and CI

Links

Publish multi-arch base images to any registry with one GitHub Action

What you get

Two modes

Inputs

Example: copy to GHCR as-is

Example: ECR, with OS packages updated, every week

Example: Docker Hub

Example: more platforms

Example: private source image

Example: BuildKit from a private mirror

How it works

Check the result

Good to know

Links

IGNOREIT: configure your ignore list once, and it's applied in every repo

What it does

Install

Choose what to ignore

Starter lists

When it runs

A walk-through

With an existing .gitignore

Keep .env.example in sync

Good to know

Already committed a secret?

Settings

Version history

Links

How to generate Cucumber test reports

Option 1: the built-in HTML report

Option 2: a Bootstrap-style report from JSON

Option 3: publish reports from CI

Keep reports out of git

Which one to pick

End-to-end test automation with Selenium and Cucumber

What you need

Set up the project

Configure Cucumber

Write the scenarios

Create a browser for each scenario

Write the steps

Run the tests

Run them in CI

Growing the suite

Configuration and change management with Packer and Ansible

Configuration vs. change management

The tools

What you need

AWS credentials

Project layout

The Packer template

The Ansible playbook

Build the image

Launch an instance from the image

With the AWS CLI

With the console

Making a change

Clean up

How to SSH into a CircleCI build container

Why SSH into a build

Step 1: set up an SSH key