Barebones
greeter
A minimal “Hello, World!” project.
Packs enough Buildkite, Docker and Jest configuration to put you on track for production.
Added in 3.4.1
Changelog
-
8.1.0: Add extension recommendations to
.vscode/extensions.json(#1556) -
8.0.1: Install specific pnpm version via Corepack (#1515)
Previously, our Dockerfiles ran
corepack enable pnpmwithout installing a specific version. This does not guarantee installation of the pnpm version specified inpackage.json, which could cause a subsequentpnpm install --offlineto run Corepack online or otherwise hang on stdin:FROM --platform=arm64 node:20-alpine RUN corepack enable pnpm{ "packageManager": "pnpm@8.15.4", "engines": { "node": ">=20" } }Corepack is about to download https://registry.npmjs.org/pnpm/-/pnpm-8.15.4.tgz. Do you want to continue? [Y/n]To avoid this issue, modify (1) Buildkite pipelines to cache on the
packageManagerproperty inpackage.json, and (2) Dockerfiles to mountpackage.jsonand runcorepack install:- seek-oss/docker-ecr-cache#v2.1.0: + seek-oss/docker-ecr-cache#v2.2.0: cache-on: - .npmrc + - package.json#.packageManager - pnpm-lock.yamlFROM --platform=arm64 node:20-alpine - RUN corepack enable pnpm + RUN --mount=type=bind,source=package.json,target=package.json \ + corepack enable pnpm && corepack install -
8.0.0: Remove
BUILDPLATFORMfrom Dockerfiles (#1350)Previously, the built-in templates made use of
BUILDPLATFORMand a fallback value:FROM --platform=${BUILDPLATFORM:-arm64} gcr.io/distroless/nodejs20-debian11- Choose the platform of the host machine running the Docker build. An AWS Graviton Buildkite agent or Apple Silicon laptop will build under
arm64, while an Intel laptop will build underamd64. - Fall back to
arm64if the build platform is not available. This maintains compatibility with toolchains like Gantry that lack support for theBUILDPLATFORMargument.
This approach allowed you to quickly build images and run containers in a local environment without emulation. For example, you could
docker buildanarm64image on an Apple Silicon laptop for local troubleshooting, while your CI/CD solution employedamd64hardware across its build and runtime environments. The catch is that your localarm64image may exhibit different behaviour, and is unsuitable for use in youramd64runtime environment without cross-compilation.The built-in templates now hardcode
--platformas we have largely converged onarm64across local, build and runtime environments:FROM --platform=arm64 gcr.io/distroless/nodejs20-debian11This approach is more explicit and predictable, reducing surprises when working across different environments and toolchains. Building an image on a different platform will be slower and rely on emulation.
- Choose the platform of the host machine running the Docker build. An AWS Graviton Buildkite agent or Apple Silicon laptop will build under
-
8.0.0: Remove account-level tags from resources (#1494)
This partially reverts #1459 and #1461 to avoid unnecessary duplication of account-level tags in our templates.
-
7.4.0: Use
propagate-environmentfor Docker Compose Buildkite plugin (#1392)This simplifies the Docker Compose environment variable configuration required for Buildkite and GitHub integrations.
In your
docker-compose.yml:services: app: - environment: - # Enable Buildkite + GitHub integrations. - - BUILDKITE - - BUILDKITE_AGENT_ACCESS_TOKEN - - BUILDKITE_BRANCH - - BUILDKITE_BUILD_NUMBER - - BUILDKITE_JOB_ID - - BUILDKITE_PIPELINE_DEFAULT_BRANCH - - BUILDKITE_STEP_ID - - GITHUB_API_TOKEN image: ${BUILDKITE_PLUGIN_DOCKER_IMAGE:-''} init: true volumes: - ./:/workdir # Mount agent for Buildkite annotations. - /usr/bin/buildkite-agent:/usr/bin/buildkite-agent # Mount cached dependencies. - /workdir/node_modulesIn your
.buildkite/pipeline.yml:steps: - commands: - pnpm lint - pnpm test env: # At SEEK, this instructs the build agent to populate the GITHUB_API_TOKEN environment variable for this step. GET_GITHUB_TOKEN: 'please' plugins: - *aws-sm - *private-npm - *docker-ecr-cache - docker-compose#v4.16.0: + environment: + - GITHUB_API_TOKEN + propagate-environment: true run: app -
7.3.1: Update to Node 20 (#1317)
Consider upgrading the Node.js version for your project across:
.nvmrcpackage.json#/engines/nodeserverless.yml@types/nodepackage version- CI/CD configuration (
.buildkite/pipeline.yml,Dockerfile, etc.)
If you are updating your AWS Lambda runtime to
nodejs20.x, consider reading the release announcement as there are some breaking changes with this upgrade. -
7.3.0: seek-oss/docker-ecr-cache 2.1 (#1266)
This update brings a new
skip-pull-from-cacheoption which is useful onWarm/Build Cachesteps.At SEEK, our build agents no longer persist their Docker build cache from previous steps. This option allows a preparatory step to proceed on a cache hit without pulling the image from ECR, which can save on average ~1 minute per build for a 2GB Docker image.
-
7.3.0: Mount npm build secret to a separate directory (#1278)
Our templated Buildkite pipelines currently retrieve a temporary
.npmrc. This file contains an npm read token that allows us to fetch private@seek-scoped packages.New projects now write this file to
/tmp/on the Buildkite agent and mount it as a secret to/root/in Docker. This separation allows you to commit a non-sensitive.npmrcto your GitHub repository while avoiding accidental exposure of the npm read token. This is especially important if you are migrating a project to pnpm, which houses some of its configuration options in.npmrc.Existing projects are generally advised to wait until we’ve paved a cleaner migration path for pnpm.
-
6.2.0: Include manifest files in CODEOWNERS (#1162)
Our templates previously excluded
package.jsonandyarn.lockfrom CODEOWNERS. This was intended to support advanced workflows such as auto-merging PRs and augmenting GitHub push notifications with custom tooling. However, we are reverting this configuration as it is more common for SEEKers to prefer a simpler CODEOWNERS-based workflow.This will not affect existing projects. If you create a new project and wish to restore the previous behaviour, you can manually extend
.github/CODEOWNERS:* @<%- ownerName %> + # Configured by Renovate + package.json + yarn.lock -
5.0.0: Bump greeter and API templates to Node.js 18 (#1011)
Node.js 18 is now in active LTS. The Lambda templates are stuck on Node.js 16 until the new AWS Lambda runtime is released.
-
5.0.0: Support AMD64 Docker builds via
BUILDPLATFORM(#1021)See the Docker documentation for more information. Note that this does not allow you to build on AMD64 hardware then deploy to ARM64 hardware and vice versa. It is provided for convenience if you need to revert to an AMD64 workflow and/or build and run an image on local AMD64 hardware.
-
4.3.0: Remove
.mefiles (#902)SEEK is moving away from Codex to off-the-shelf software powered by Backstage
catalog-info.yamlfiles.At the moment we’re only asking teams to document their systems, which typically span across multiple repositories. We may add
catalog-info.yamlfiles back to the templates if there’s a need for teams to document their components at a repository level. -
4.3.0: Use ARM64 architecture (#873)
We now recommend building and running projects on ARM64 hardware for greater cost efficiency. This requires a Graviton-based Buildkite cluster; see our ARM64 guide for more information.
-
4.2.1: Time out Buildkite test steps after 10 minutes (#842)
Successful testing and linting should complete within this window. This timeout prevents commands from hanging and indefinitely preoccupying your Buildkite agents.
steps: - label: 🧪 Test & Lint + timeout_in_minutes: 10 -
4.2.0: Propagate Buildkite environment variables for lint autofixing (#800)
-
4.2.0: Exclude DOM type definitions by default (#822)
TypeScript will now raise compiler errors when DOM globals like
documentandwindoware referenced in new projects. This catches unsafe usage of Web APIs that will throw exceptions in a Node.js context.If you are developing a new npm package for browser use or require specific Node.js-compatible Web APIs like the Encoding API, you can opt in to DOM type definitions in your
tsconfig.json:{ "compilerOptions": { - "lib": ["ES2020"] + "lib": ["DOM", "ES2020"] } }If you have an existing backend project, you can opt out of DOM type definitions in your
tsconfig.json.For Node.js 14:
{ "compilerOptions": { + "lib": ["ES2020"], "target": "ES2020" } }For Node.js 16:
{ "compilerOptions": { + "lib": ["ES2021"], "target": "ES2021" } } -
4.1.1: Disable type checking in tests (#787)
Newly initialised projects will skip TypeScript type checking on
skuba testas it’s already covered byskuba lint. You can now iterate on your tests without running into annoying compilation errors like TS6133 (unused declarations).This will be defaulted for existing projects in a future major version. You can opt in early by setting the
globalsconfiguration option in yourjest.config.ts:export default Jest.mergePreset({ globals: { 'ts-jest': { // seek-oss/skuba#626 isolatedModules: true, }, }, // Rest of config }); -
4.0.0: Use
--enable-source-maps(#761)Stable source map support has landed in Node.js 14.18+ via the built-in
--enable-source-mapsoption.We recommend migrating off of custom source map implementations in favour of this option. Upgrading to skuba-dive v2 will remove
source-map-supportfrom theskuba-dive/registerhook.For a containerised application, update your Dockerfile:
- FROM gcr.io/distroless/nodejs:12 AS runtime + FROM gcr.io/distroless/nodejs:16 AS runtime + # https://nodejs.org/api/cli.html#cli_node_options_options + ENV NODE_OPTIONS=--enable-source-mapsFor a Serverless Lambda application, update your
serverless.yml:provider: - runtime: nodejs12.x + runtime: nodejs14.x functions: Worker: environment: + # https://nodejs.org/api/cli.html#cli_node_options_options + NODE_OPTIONS: --enable-source-mapsFor a CDK Lambda application, update your stack:
new aws_lambda.Function(this, 'worker', { - runtime: aws_lambda.Runtime.NODEJS_12_X, + runtime: aws_lambda.Runtime.NODEJS_14_X, environment: { + // https://nodejs.org/api/cli.html#cli_node_options_options + NODE_OPTIONS: '--enable-source-maps', }, }); -
3.16.0: Use correct
environmentkey indocker-compose.yml(#654) -
3.16.0: Bump non-Lambda templates to Node.js 16 (#633)
Node.js 16 is now in active LTS. The Lambda templates are stuck on Node.js 14 until the new AWS Lambda runtime is released.
-
3.16.0: Ignore
.gantryYAML paths via.prettierignore(#636)Gantry resource and value files often live in the
.gantrysubdirectory and may use non-standard template syntax. -
3.16.0: Propagate environment variables for GitHub annotations (#642)
This enables GitHub annotations for newly-initialised projects with the appropriate Buildkite configuration.
-
3.15.2: Remove README tables of contents (#596)
GitHub’s Markdown renderer now generates its own table of contents.
-
3.15.2: pino-pretty ^6.0.0 (#594)
pino-pretty@7 requires pino@7, which has not been released on its stable channel yet.
-
3.15.1: Remove
unknownspecifier in catch clauses (#580)Strict TypeScript 4.4 now defaults to typing catch clause variables as
unknown. -
3.15.0: Configure environment variables and volume mounts for Buildkite annotations (#558)
-
3.15.0: Remove
@types/noderesolution override (#498)Jest 27.1 is compatible with newer versions of
@types/node. -
3.15.0: Remove Yarn cache from worker Docker images (#499)
This shrinks the cached Docker images that our worker templates generate.
-
3.14.3: Force
@jest/typesresolution to fix clean installs (#468) -
3.14.3: Use Docker Build secrets (#476)
-
3.14.3: Group Buildkite pipeline anchors (#474)
This provides a bit more structure to our
pipeline.ymls and allows anchored plugins to be recognised by Renovate. -
3.14.3: Default Docker Compose image to empty string (#469)
This suppresses Docker Compose CLI warnings and errors when running outside of Buildkite.
-
3.14.3: Use BUILDKITE_PIPELINE_DEFAULT_BRANCH in
pipeline.yml(#475) -
3.14.2: Use
seek-oss/docker-ecr-cacheBuildkite plugin (#453) -
3.14.0: Prune
devDependenciesinstead of installing twice in Docker (#435)The template-bundled Dockerfiles would previously run
yarn installtwice to build a separate stage for productiondependenciesonly. These have been updated to correctly share the Yarn cache across stages and to useyarn install --productionto perform offline pruning. -
3.13.0: Upgrade to Node 14 (#347)
Node.js 14 is now supported on AWS Lambda. This lets us upgrade the Node.js requirement for skuba’s templates.
This should only impact newly created projects. You can use the template changes in this PR as an example of how to upgrade an existing project. A future version of skuba may include a fixup command to automatically upgrade your project to the most recent LTS release.
-
3.13.0: Add GitHub repository settings and Renovate to init checklist (#388)
-
3.12.0: Enable retry of successful deployment steps (#311)
This should be used with caution, but may be necessary if you need to rapidly roll back a broken deployment.
-
3.10.0: Recommend
@seek/logger(#225)This provides logging structure, trimming and redaction over plain Pino.
-
3.7.7: Remove explicitly set NPM_READ_TOKEN from Dockerfile commands (#168)