Hi team,
I opened four small, single-issue fixes about two weeks ago and would appreciate a review when someone has time. All follow the PR template and CI is green on each.
main ← Krish6115:fix/helm-redis-connection-string
opened 10:20AM - 13 Oct 26 UTC
## Description
In `helm-charts/infisical-standalone-postgres/templates/_helpers.… tpl`, the Redis connection string helper `infisical.redisConnectionString` resolves `$serviceName` via `infisical.redisServiceName` (which dynamically checks `redis.fullnameOverride` and Bitnami master service conventions). However, on line 123, the connection string template hardcoded `"redis-master"` instead of using the resolved `$serviceName`.
This caused deployments specifying `redis.fullnameOverride` to construct an invalid `REDIS_URL` pointing to `redis-master:6379` rather than `<redis.fullnameOverride>-master:6379`.
This PR fixes line 123 to use `$serviceName`, bumps the chart version to `1.11.1`, updates the version badge in `README.md`, and documents the fix in `CHANGELOG.md`.
Closes #2365
## Type of Change
- [x] Bug fix (non-breaking change which fixes an issue)
- [ ] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
- [ ] Documentation update
## How Has This Been Tested?
Tested locally using `helm template` (v3.17.0) against `helm-charts/infisical-standalone-postgres`:
1. **Default values:** Renders `redis://default:mysecretpassword@redis-master:6379` (100% backward compatible).
2. **With `redis.fullnameOverride=custom-redis`:**
- Redis subchart master service renders: `metadata.name: custom-redis-master`
- Infisical deployment renders: `REDIS_URL: redis://default:mysecretpassword@custom-redis-master:6379`
- Verified that the service name matches the host in `REDIS_URL`.
3. **With custom release name (`prod-stack`) and `redis.fullnameOverride=""`:**
- Redis master service renders: `metadata.name: prod-stack-master`
- Infisical deployment renders: `REDIS_URL: redis://default:mysecretpassword@prod-stack-master:6379`
## Checklist
- [x] My code follows the style guidelines of this project
- [x] I have performed a self-review of my own code
- [x] I have commented my code, particularly in hard-to-understand areas
- [x] I have made corresponding changes to the documentation (Chart.yaml, README.md, CHANGELOG.md)
- [x] My changes generate no new warnings
main ← Krish6115:fix/backend-docker-healthcheck
opened 10:20AM - 13 Oct 26 UTC
## Description
In `backend/Dockerfile`, the `HEALTHCHECK` command invokes `CMD n… ode healthcheck.js`. However, no `healthcheck.js` exists in `backend/` (the only `healthcheck.js` in the repository is located under `frontend/scripts/` and targets port 3000). As a result, the Docker healthcheck fails when running the backend container directly.
This PR replaces the missing script invocation with `curl -f http://localhost:${PORT:-4000}/api/status || exit 1`.
- `curl` is already installed via `apt-get` on line 82 of the runtime stage in `backend/Dockerfile`.
- Uses `${PORT:-4000}` to honor dynamic port overrides while defaulting to port 4000.
- Directly matches the existing healthcheck pattern used in `docker-compose.dev.yml` (`test: ["CMD", "curl", "-f", "http://localhost:4000/api/status"]`) and recommended in `docs/self-hosting/guides/production-hardening.mdx`.
Closes #1541
## Type of Change
- [x] Bug fix (non-breaking change which fixes an issue)
- [ ] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
- [ ] Documentation update
## How Has This Been Tested?
1. Verified file existence across the repository: confirmed `healthcheck.js` only exists under `frontend/scripts/healthcheck.js` and does not exist in `backend/`.
2. Verified `backend/Dockerfile`: confirmed `curl` is installed via `apt-get` on line 82 of the runtime stage.
3. Verified consistency with `docker-compose.dev.yml` line 117 and `docs/self-hosting/guides/production-hardening.mdx` line 290.
*(Note: Verified by code inspection and pattern consistency with existing compose/docs configurations; local container execution was not run as Docker daemon was unavailable in the local environment).*
## Checklist
- [x] My code follows the style guidelines of this project
- [x] I have performed a self-review of my own code
- [x] I have commented my code, particularly in hard-to-understand areas
- [x] I have made corresponding changes to the documentation
- [x] My changes generate no new warnings
PR #8585 (fixes #2365 ): in the standalone-postgres Helm chart, infisical.redisConnectionString resolved the Redis service name but still printed a hardcoded “redis-master”, so redis.fullnameOverride or a custom release name produced a wrong REDIS_URL. With helm template, default values render exactly as before, and an override now renders custom-redis-master.
PR #8586 (fixes #1541 ): backend/Dockerfile’s HEALTHCHECK ran node healthcheck.js, which doesn’t exist, so it always failed. It now uses curl against /api/status, the same call docker-compose.dev.yml uses (curl is already installed in the runtime stage). Verified by code inspection only, as I couldn’t run a container locally.
PR #8590 (fixes #2307 ): the Token Auth docs referenced a login operation and a 7200s default TTL copied from Universal Auth. Token Auth has no login endpoint, and the default is 2592000s. I corrected the text and added a sample request. Not rendered locally with Mintlify.
PR #8591 (fixes #2545 ): GitLab’s GET /groups/:id/projects defaults include_subgroups to false, so projects in nested subgroups never appeared in the integration picker. One added parameter. Not tested against a live GitLab instance.
Happy to adjust, split or close any of these. Thanks for taking a look!