SPIKE Release Management

This document provides an overview of how the cut a SPIKE release, including testing guidelines and instructions.

We Use Humans as Push-buttons

At the moment, we don’t have a CI pipeline in place for the release process. Most of the operations mentioned here are manual. However, we are actively working on improving and automating the release process. This document will be updated as we introduce more automation into the pipeline.

Below, you will find detailed instructions and examples to guide contributors through the release and testing process.

This document is targeted for core contributors who are responsible for managing the release cuts of SPIKE. It provides detailed instructions to ensure a smooth and reliable release process.

Before Every Release

Before every release:

Run the unit tests
Run the following smoke test documented in the next section.
If everything passes, update NexusVersion, PilotVersion and KeeperVersion in $WORKSPACE/spike/internal/config/config.go
Update any necessary documentation.
Update the changelog.
Update the documentation snapshots page.

Release process:

Publish documentation by running zola build in ./docs-src and then copying the generated html in ./docs-src/public into /.docs.
Merge all the changes to the main branch.
Tag a version and convert that version to a *release on GitHub.
- Make sure you GPG sign your tag.
Copy the current version’s changelog over to the release notes on GitHub.
On a Mac machine follow cross-platform build instructions to generate binaries.
Add binaries to the release as assets.
Announce the release in relevant channels.
You are all set.

SPIKE Smoke Tests

How About Automation?

There is a partially-working ./ci/test/main.go binary that you can play with. But unless that is fixed, we’ll have to run SPIKE smoke test manually.

./ci/test/main.go is designed for integration tests, and it assumes a working SPIKE and SPIKE environment to execute properly.

Note that these are instructions for a manual smoke test, and it’s not a replacement for a full integration test. We may add more steps, but we’ll keep it lightweight. — Passing the smoke test means that the core components and the features of the system are reliably functional.

Start the Test Environment

make start

# enter user password if prompted

# wait for the following prompt:
# <<
# >
# > Everything is set up.
# > You can now experiment with SPIKE.
# >
# <<
# > >> To begin, run './spike' on a separate terminal window.
# <<
# >
# > When you are done with your experiments, you can press 'Ctrl+C'
# > on this terminal to exit and cleanup all background processes.
# >
# <<

Create a Secret

spike secret put /acme/db user=spike pass=SPIKERocks
# Output:
# OK

Verify secret:

spike secret get /acme/db
# Output:
# pass: SPIKERocks
# user: spike

Create a Policy

spike policy create --name=workload-can-read \
  --path="/tenants/demo/db/*" \
  --spiffeid="^spiffe://spike.ist/workload/*" \
  --permissions="read"

Verify the Policy Creation

spike policy list

# Sample output:
# [
#  {
#    "id": "872478b1-cef6-45c1-8417-1de82995aaa4",
#    "name": "workload-can-read",
#    "spiffeIdPattern": "^spiffe://spike.ist/workload/*",
#    "pathPattern": "/tenants/demo/db/*",
#    "permissions": [
#      "read"
#    ],
#    "createdAt": "2025-02-15T07:43:47.306286591-08:00",
#    "createdBy": ""
#  }
# ]

Test the Demo Workload

./examples/consume-secrets/demo-create-policy.sh
./examples/consume-secrets/demo-register-entry.sh

./demo

# Output
# Secret found:
# password: SPIKE_Rocks
# username: SPIKE

If everything went well so far, we can assume that the current SPIKE release is in a good enough shape.