chore: release 0.2.0 - #151
AlejandroEsquivel wants to merge 2 commits into
Conversation
8e020dd to
71d42c2
Compare
![blocksorg[bot]](https://avatars.githubusercontent.com/in/931482?s=60&v=4){kind=small}
| ```bash | ||
| # Downloads the release bundle, checks it, and moves into the AWS folder. The bundle holds | ||
| # the Helm chart at chart/blue and the OpenTofu module at infra/aws. | ||
| VERSION=0.1.0 |
There was a problem hiding this comment.
The 0.2.0 production guide instructs readers to download the blue-deployment-v0.1.0.tar.gz release bundle. Anyone copy-pasting this block will deploy the previous release instead of 0.2.0.
This leaks in from apps/docs/next/deployment/production.mdx, which release-version.mjs copies verbatim (only rewriting /next/ links). Update the source file to use VERSION=0.2.0 (or a placeholder like <VERSION>) and let the finalize job re-freeze the snapshot.
Severity 7/10 · View on dashboard
| tofu output -json helm_values > "$BLUE_HELM_GENERATED_FILE" | ||
|
|
||
| # Pins the image to an exact build. The chart refuses a moving tag in production. | ||
| export BLUE_IMAGE_DIGEST="$(docker buildx imagetools inspect ghcr.io/blocksorg/blue:0.1.0 | awk '/^Digest:/{print $2}')" |
There was a problem hiding this comment.
The 0.2.0 guide pins the deployment image to ghcr.io/blocksorg/blue:0.1.0. This deploys the previous release's image and skips the 0.2.0 fixes and features.
Same root cause as the VERSION=0.1.0 block above: the snapshot copies apps/docs/next/deployment/production.mdx without rewriting prose version literals. Update the source file to reference the 0.2.0 image tag and re-run finalize.
Severity 7/10 · View on dashboard
6026186 to
a1658e1
Compare
| ```bash | ||
| # Downloads the release bundle, checks it, and moves into the AWS folder. The bundle holds | ||
| # the Helm chart at chart/blue and the OpenTofu module at infra/aws. | ||
| VERSION=0.1.0 |
There was a problem hiding this comment.
The 0.2.0 production guide still sets VERSION=0.1.0, so readers following these steps will download the v0.1.0 deployment bundle instead of v0.2.0. Update this to VERSION=0.2.0. The same stale reference exists in apps/docs/next/deployment/production.mdx; fix it there and regenerate the snapshot so future releases don't inherit it.
Severity 8/10 · View on dashboard
| tofu output -json helm_values > "$BLUE_HELM_GENERATED_FILE" | ||
|
|
||
| # Pins the image to an exact build. The chart refuses a moving tag in production. | ||
| export BLUE_IMAGE_DIGEST="$(docker buildx imagetools inspect ghcr.io/blocksorg/blue:0.1.0 | awk '/^Digest:/{print $2}')" |
There was a problem hiding this comment.
The image tag is hardcoded to ghcr.io/blocksorg/blue:0.1.0. For the 0.2.0 release docs this should reference the 0.2.0 image, otherwise operators will pin the previous release's digest. Update to 0.2.0 and fix the same reference in next/deployment/production.mdx.
Severity 8/10 · View on dashboard
| MINIO_ROOT_USER=replace-local-storage-user | ||
| MINIO_ROOT_PASSWORD=replace-local-storage-password | ||
| # Version label displayed beside the dashboard logo; release builds inject this into the image. | ||
| BLUE_DEPLOYMENT_VERSION=0.1.0 |
There was a problem hiding this comment.
The 0.2.0 local Compose docs still show BLUE_DEPLOYMENT_VERSION=0.1.0 in the example .env. This mislabels the deployment as 0.1.0 in the dashboard. Update to 0.2.0 and fix the same reference in next/development/local-compose.mdx.
Severity 7/10 · View on dashboard
|
|
||
| | Variable | Effect | | ||
| | --- | --- | | ||
| | `BLUE_VERSION=0.1.0` | Install a specific release instead of the latest. | |
There was a problem hiding this comment.
The 0.2.0 install reference still uses BLUE_VERSION=0.1.0 as the example for pinning a specific release. Readers copying this will install the previous release. Update to 0.2.0 and fix the same reference in next/cli/commands.mdx.
Severity 7/10 · View on dashboard
1f8a940 to
3027ca2
Compare
| ```bash | ||
| # Downloads the release bundle, checks it, and moves into the AWS folder. The bundle holds | ||
| # the Helm chart at chart/blue and the OpenTofu module at infra/aws. | ||
| VERSION=0.1.0 |
There was a problem hiding this comment.
The 0.2.0 release docs instruct readers to download the v0.1.0 deployment bundle. Anyone following this guide will install the previous release. Update to VERSION=0.2.0.
Severity 8/10 · View on dashboard
| tofu output -json helm_values > "$BLUE_HELM_GENERATED_FILE" | ||
|
|
||
| # Pins the image to an exact build. The chart refuses a moving tag in production. | ||
| export BLUE_IMAGE_DIGEST="$(docker buildx imagetools inspect ghcr.io/blocksorg/blue:0.1.0 | awk '/^Digest:/{print $2}')" |
There was a problem hiding this comment.
This hardcodes the previous release image tag 0.1.0. Since VERSION is defined above, use ghcr.io/blocksorg/blue:${VERSION} (or 0.2.0) so the digest pin matches the release being documented.
Severity 8/10 · View on dashboard
| MINIO_ROOT_USER=replace-local-storage-user | ||
| MINIO_ROOT_PASSWORD=replace-local-storage-password | ||
| # Version label displayed beside the dashboard logo; release builds inject this into the image. | ||
| BLUE_DEPLOYMENT_VERSION=0.1.0 |
There was a problem hiding this comment.
The 0.2.0 snapshot still shows BLUE_DEPLOYMENT_VERSION=0.1.0. Update to 0.2.0 so the local-compose example matches the release version.
Severity 7/10 · View on dashboard
|
|
||
| | Variable | Effect | | ||
| | --- | --- | | ||
| | `BLUE_VERSION=0.1.0` | Install a specific release instead of the latest. | |
There was a problem hiding this comment.
The 0.2.0 docs use BLUE_VERSION=0.1.0 as the example for pinning an installer release. Update to 0.2.0 so readers install the current release.
Severity 7/10 · View on dashboard
|
|
||
| ```bash | ||
| cd apps/docs | ||
| npm run release:docs -- 0.1.0 |
There was a problem hiding this comment.
The 0.2.0 contributing guide still demonstrates npm run release:docs -- 0.1.0. Update to 0.2.0 to match the current release snapshot.
Severity 7/10 · View on dashboard
| ```bash | ||
| # Downloads the release bundle, checks it, and moves into the AWS folder. The bundle holds | ||
| # the Helm chart at chart/blue and the OpenTofu module at infra/aws. | ||
| VERSION=0.1.0 |
There was a problem hiding this comment.
The production guide in the frozen 0.2.0 docs still tells users to download the v0.1.0 deployment bundle. Since this page is the verified EKS walkthrough for the 0.2.0 release, VERSION should be 0.2.0, and the image tag below should also point at 0.2.0. Update apps/docs/next/deployment/production.mdx as well and re-freeze the snapshot so check-release-snapshot.mjs stays green.
Severity 8/10 · View on dashboard
| tofu output -json helm_values > "$BLUE_HELM_GENERATED_FILE" | ||
|
|
||
| # Pins the image to an exact build. The chart refuses a moving tag in production. | ||
| export BLUE_IMAGE_DIGEST="$(docker buildx imagetools inspect ghcr.io/blocksorg/blue:0.1.0 | awk '/^Digest:/{print $2}')" |
There was a problem hiding this comment.
This example resolves the digest of ghcr.io/blocksorg/blue:0.1.0, while the surrounding guide installs chart 0.2.0. A reader following this literally would pin the previous release's image. Change the tag to 0.2.0 (and update the apps/docs/next source) before freezing the release snapshot.
Severity 8/10 · View on dashboard
66c1216 to
cfa68c9
Compare
| ```bash | ||
| # Downloads the release bundle, checks it, and moves into the AWS folder. The bundle holds | ||
| # the Helm chart at chart/blue and the OpenTofu module at infra/aws. | ||
| VERSION=0.1.0 |
There was a problem hiding this comment.
The 0.2.0 production guide still tells readers to download the v0.1.0 release bundle (VERSION=0.1.0). Users following this step will install the previous release instead of 0.2.0. Update this literal to 0.2.0 before the snapshot is frozen.
Severity 7/10 · View on dashboard
| tofu output -json helm_values > "$BLUE_HELM_GENERATED_FILE" | ||
|
|
||
| # Pins the image to an exact build. The chart refuses a moving tag in production. | ||
| export BLUE_IMAGE_DIGEST="$(docker buildx imagetools inspect ghcr.io/blocksorg/blue:0.1.0 | awk '/^Digest:/{print $2}')" |
There was a problem hiding this comment.
The image digest lookup still references the ghcr.io/blocksorg/blue:0.1.0 tag. Since the rest of the guide is being released as 0.2.0, this should be 0.2.0 so the digest query resolves against the correct image.
Severity 7/10 · View on dashboard
| ```bash | ||
| # Downloads the release bundle, checks it, and moves into the AWS folder. The bundle holds | ||
| # the Helm chart at chart/blue and the OpenTofu module at infra/aws. | ||
| VERSION=0.1.0 |
There was a problem hiding this comment.
The 0.2.0 documentation snapshot still references the previous release in command examples. VERSION=0.1.0 here and the ghcr.io/blocksorg/blue:0.1.0 image tag on line 72 will lead users to download or inspect the old release. Because check-release-snapshot.mjs requires the snapshot to be an exact copy of next/ (modulo /next/ links), update the examples in apps/docs/next/deployment/production.mdx first, then regenerate the 0.2.0 snapshot.
Severity 7/10 · View on dashboard
| MINIO_ROOT_USER=replace-local-storage-user | ||
| MINIO_ROOT_PASSWORD=replace-local-storage-password | ||
| # Version label displayed beside the dashboard logo; release builds inject this into the image. | ||
| BLUE_DEPLOYMENT_VERSION=0.1.0 |
There was a problem hiding this comment.
BLUE_DEPLOYMENT_VERSION=0.1.0 in the 0.2.0 docs will label the local deployment with the previous release. Update the example in apps/docs/next/development/local-compose.mdx and regenerate the 0.2.0 snapshot so the snapshot check stays green.
Severity 7/10 · View on dashboard
1 participant
🤖 I have created a release beep boop
0.2.0 (2026-09-16)
Features
Bug Fixes
Documentation
Code Refactoring
This PR was generated with Release Please. See documentation.