* Bump version to next iteration after v0.7.4-alpha.2 release
* alpha.3
---------
Signed-off-by: Juan José Mata <juanjo.mata@gmail.com>
Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
Co-authored-by: Juan José Mata <jjmata@jjmata.com>
Co-authored-by: Juan José Mata <juanjo.mata@gmail.com>
* Bump version to next iteration after v0.7.3-alpha.4 release
* Use GitHub token for automated version bump PRs
---------
Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
2026-07-22 02:53:44 +02:00
Juan José Mataandgithub-actions[bot] <github-actions[bot]@users.noreply.github.com>
* Bump version to next iteration after v0.7.3-alpha.3 release
* Fix automated version bump pull requests
---------
Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
* Bump version to next iteration after v0.7.2-alpha.8 release
* Version bump
---------
Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
* chore(helm): bump pipelock to 2.5.0 and surface 2.5 config
Bumps pipelock.image.tag from 2.2.0 to 2.5.0 and exposes the most
relevant 2.5 features as structured Helm values:
- pipelock.requestBodyScanning: scan outbound bodies and sensitive
headers for prompt-injection and DLP payloads. Disabled by default;
roll out with action=warn before flipping to block.
- pipelock.healthWatchdog: structured config for the wedge-detection
watchdog with an exposeSubsystems toggle for /health detail.
- pipelock.mcpToolPolicy.rules: structured values for rendering
mcp_tool_policy.rules including redirect-profile references.
Also fixes a latent config-validation regression: pipelock 2.x rejects
an enabled mcp_tool_policy with no rules, but the chart previously
defaulted to enabled=true with an empty rules list, which hard-fails
'pipelock check'. The default is now enabled=false; operators must
explicitly enable and provide at least one rule.
Refreshes README, CHANGELOG, docs/hosting/pipelock.md, docs/hosting/ai.md,
compose example pin comment, and pipelock.example.yaml to call out 2.5
highlights (Audit Packet v0 verifiers, SPIFFE-strict envelopes, scanner
attribution on MCP block receipts, pipelock doctor). Also fixes a stale
docs/hosting/mcp.md reference to the removed compose.example.pipelock.yml.
* chore(helm): fail helm template when mcp_tool_policy enabled with no rules
Adds a guard in asserts.tpl so an operator who sets
pipelock.mcpToolPolicy.enabled=true without populating
pipelock.mcpToolPolicy.rules gets a clear render-time error instead
of a container crash-loop with the pipelock validation message.
Per CodeRabbit feedback on #1913.
* Versions
---------
Co-authored-by: Juan José Mata <jjmata@jjmata.com>
* fix(helm): skip Redis/DB auto-wiring when extraEnv override is set
Setting rails.extraEnv.REDIS_URL or DATABASE_URL caused the chart to
emit the URL twice, once from auto-wiring and once from the generic
extraEnv loop. Server-side apply rejected the Deployment with a
duplicate-key error.
The auto-wiring path also added REDIS_PASSWORD / DB_PASSWORD env vars
sourced from secret keys that external-service users typically don't
have, so even after deduplicating, pods failed CreateContainerConfigError.
Gate the auto-emit block on the absence of a user override. The
extraEnv loop emits the URL once and no *_PASSWORD env is injected.
Chart-managed Redis/Postgres behavior is unchanged.
* fix(helm): guard extraEnv index against nil
CodeRabbit flagged that `index $ctx.Values.rails.extraEnv "DATABASE_URL"`
(and the REDIS_URL equivalent) panic if a user sets `rails.extraEnv: null`
or omits the field entirely. Wrap with `default (dict)` first, matching
the defensive pattern already used elsewhere in this template.
* fix(helm): use hasKey for extraEnv presence check
Switch from `(index $railsExtraEnv "URL_KEY")` to `hasKey $railsExtraEnv
"URL_KEY"`. With `index`, a user setting `DATABASE_URL: ""` or
`REDIS_URL: ""` in extraEnv would still trigger chart auto-injection
(empty string is falsy), recreating the duplicate-emission bug for the
empty-value case. `hasKey` keys the gate on presence, so any explicit
override (including empty) suppresses auto-wiring.
* Extract version to .sure-version file and add Sentry release tracking
Move the hardcoded version string to a `.sure-version` file at the repo
root so it can be read by both the Rails version initializer and other
tooling. Configure `config.release` in the Sentry initializer to tag
errors with the app version.
https://claude.ai/code/session_01KfUgF42B3exoU2vpErqJyW
* Use .sure-version as single source of truth in Helm CI workflows
Update chart-ci, chart-release, and publish workflows to read the app
version from .sure-version instead of regex-parsing version.rb. The
pre-release bump job now writes directly to .sure-version and stages it
for commit.
https://claude.ai/code/session_01KfUgF42B3exoU2vpErqJyW
* Guard empty .sure-version fallback
* fix: sync Helm chart version with .sure-version
* Moving on to `v0.7.1-alpha.*` with this
* Defensive rescue
* Getting fancy with versions now
---------
Signed-off-by: Juan José Mata <juanjo.mata@gmail.com>
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: SureBot <sure-bot@we-promise.com>
Co-authored-by: sure-admin <sure-admin@splashblot.com>
- Helm chart default pipelock.image.tag bumped from 2.0.0 to 2.2.0
(three minor releases behind latest)
- README: pipelock CI scan status badge added to the existing badge row
- charts/sure/README.md, docs/hosting/pipelock.md, pipelock.example.yaml:
refreshed feature notes to reference the upstream changelog rather than
pinning to a single version
- compose.example.ai.yml: pin example comment bumped to :2.2.0
- Workflow pin (@v2) unchanged — floating major tag picks up 2.2.x
* chore(helm): bump pipelock to v2.0.0 with trusted domains and redirect profiles
- Bump pipelock image tag from 1.5.0 to 2.0.0
- Add first-class Helm values for trustedDomains and mcpToolPolicy.redirectProfiles
- Update CI GitHub Action from @v1 to @v2
- Update compose example, config reference, and docs with v2.0 features
* Releasing this today in `alpha` form
---------
Co-authored-by: Juan José Mata <jjmata@jjmata.com>
