Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Repository YAML (base), Organization UI (inherited) Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
📝 WalkthroughWalkthroughThe development Compose configuration updates Authentik server and worker images to ChangesAuthentik development stack
Estimated code review effort: 2 (Simple) | ~5 minutes 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@docker-compose.dev.yml`:
- Line 283: Update the PostgreSQL image change for the existing authentik-db
volume by documenting either a pg_dumpall/restore migration from the PostgreSQL
13 data directory to PostgreSQL 18’s /var/lib/postgresql/18/docker path, or an
explicit destructive volume reset procedure. Ensure the documentation clearly
tells developers how to handle the existing volume before starting the new
image.
- Line 228: Document a safe migration procedure for the Authentik and PostgreSQL
version changes in the development compose configuration, including database
backup and required sequential Authentik upgrades from 2023.10.7, or clearly
describe removing the authentik-db volume as a development-only reset before
starting 2026.5. Reference the affected Authentik image configuration and
PostgreSQL volume mount path, and preserve the warning that existing data must
not be started directly on the new versions.
🪄 Autofix
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository YAML (base), Organization UI (inherited)
Review profile: CHILL
Plan: Pro
Run ID: eec61e19-e26c-4da3-ba37-42c8e3057364
📒 Files selected for processing (1)
docker-compose.dev.yml
| - sso | ||
| - sso-only | ||
| image: ${AUTHENTIK_IMAGE:-ghcr.io/goauthentik/server}:${AUTHENTIK_TAG:-2023.10.7} | ||
| image: ${AUTHENTIK_IMAGE:-ghcr.io/goauthentik/server}:${AUTHENTIK_TAG:-2026.5} |
There was a problem hiding this comment.
🗄️ Data Integrity & Integration | 🟠 Major | 🏗️ Heavy lift
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
compose_file=docker-compose.dev.yml
git diff --unified=12 -- "$compose_file"
rg -n -C 6 'AUTHENTIK_TAG|authentik-worker|authentik-db' "$compose_file"
db_container="$(docker compose -f "$compose_file" ps -q authentik-db 2>/dev/null || true)"
if [[ -n "$db_container" ]]; then
docker inspect "$db_container" \
--format '{{range .Mounts}}{{println .Name .Source .Destination}}{{end}}'
fiRepository: SpecterOps/BloodHound
Length of output: 2992
🏁 Script executed:
#!/bin/bash
set -euo pipefail
printf '%s\n' '--- Authentik references ---'
rg -n -i -C 4 'authentik|AUTHENTIK_TAG|2023\.10\.7|2026\.5|upgrade|reset.*database|database.*reset' \
--glob '!node_modules' --glob '!dist' --glob '!build' .
printf '%s\n' '--- Relevant compose history ---'
git log --oneline --all -- docker-compose.dev.yml | head -20
printf '%s\n' '--- File header ---'
sed -n '1,25p' docker-compose.dev.yml
printf '%s\n' '--- Current and parent Authentik image lines ---'
git show HEAD^:docker-compose.dev.yml 2>/dev/null | rg -n 'AUTHENTIK_TAG|authentik-worker' || true
git show HEAD:docker-compose.dev.yml 2>/dev/null | rg -n 'AUTHENTIK_TAG|authentik-worker' || trueRepository: SpecterOps/BloodHound
Length of output: 50379
🌐 Web query:
Authentik 2026.5 upgrade sequential major versions 2023.10.7
💡 Result:
Authentik requires a strict, sequential upgrade path for all major versions [1][2][3]. You cannot upgrade directly from version 2023.10.7 to 2026.5, as doing so will likely cause database migration failures, potential data corruption, or system instability [4][5]. To upgrade from 2023.10.7 to 2026.5, you must follow the sequential order of major releases, upgrading to the latest minor version (the latest.x release) of each intermediate major release before proceeding to the next [1][6]. The required upgrade path involves upgrading through the major versions released between 2023.10 and 2026.5. Based on the documented release history, this path generally looks like this: 1. Ensure you are on the latest 2023.10.x version [1]. 2. Upgrade to the latest 2025.12.x version [7][8]. 3. Upgrade to the latest 2026.2.x version [7]. 4. Finally, upgrade to the latest 2026.5.x version [2]. Before beginning any upgrade, you must back up your database [1]. If you encounter migration errors during the process, do not skip versions; instead, revert to your backup and ensure each step is completed fully before moving forward [6][5]. Always verify that your authentik instance and all outposts are updated to the same version simultaneously [1][2].
Citations:
- 1: https://docs.goauthentik.io/install-config/upgrade/
- 2: https://docs.goauthentik.io/releases/2026.5/
- 3: https://github.com/goauthentik/authentik/blob/95413c94/website/docs/releases/2026/v2026.5.md
- 4: Prevent application start/migration if sequential upgrade path is skipped goauthentik/authentik#20836
- 5: Migration authentik_core.0058_setup fails on upgrade from v2025.10.2 to v2026.5.0 goauthentik/authentik#22688
- 6: https://github.com/goauthentik/authentik/blob/9a974f14/website/docs/install-config/upgrade.mdx
- 7: https://docs.goauthentik.io/releases/
- 8: https://docs.goauthentik.io/releases/2025.12/
🏁 Script executed:
#!/bin/bash
set -euo pipefail
printf '%s\n' '--- Compose change ---'
git diff --unified=8 -- docker-compose.dev.yml || true
printf '%s\n' '--- Authentik lines in parent and current revisions ---'
for rev in HEAD^ HEAD; do
printf '%s\n' "--- $rev ---"
git show "$rev:docker-compose.dev.yml" 2>/dev/null \
| grep -n -E 'AUTHENTIK_TAG|authentik-worker|authentik-db|authentik:' || true
done
printf '%s\n' '--- Compose header and project guidance ---'
sed -n '1,35p' docker-compose.dev.yml
printf '%s\n' '--- LICENSE.header ---'
cat LICENSE.header 2>/dev/null || true
printf '%s\n' '--- Authentik-specific documentation files ---'
git ls-files | grep -Ei 'authentik|compose|development|contribut' | head -100Repository: SpecterOps/BloodHound
Length of output: 7467
🏁 Script executed:
#!/bin/bash
set -euo pipefail
python3 - <<'PY'
from urllib.request import urlopen
from urllib.error import HTTPError, URLError
urls = [
"https://docs.goauthentik.io/install-config/upgrade/",
"https://docs.goauthentik.io/releases/2026.5/",
]
for url in urls:
print(f"--- {url} ---")
try:
text = urlopen(url, timeout=15).read().decode("utf-8", "replace")
lower = text.lower()
terms = ("sequential", "major", "2023.10", "2025.12", "2026.2", "backup")
for term in terms:
positions = [i for i in range(len(lower)) if lower.startswith(term, i)]
for pos in positions[:3]:
print(text[max(0, pos-250):pos+500].replace("\n", " ")[:800])
except (HTTPError, URLError, TimeoutError) as exc:
print(type(exc).__name__, exc)
PYRepository: SpecterOps/BloodHound
Length of output: 560
🏁 Script executed:
#!/bin/bash
set -euo pipefail
printf '%s\n' '--- Database image and mount change ---'
for rev in HEAD^ HEAD; do
printf '%s\n' "--- $rev ---"
git show "$rev:docker-compose.dev.yml" 2>/dev/null \
| sed -n '279,297p'
done
printf '%s\n' '--- Authentik upgrade text from upstream documentation ---'
python3 - <<'PY'
import ssl
from urllib.request import urlopen
urls = [
"https://raw.githubusercontent.com/goauthentik/authentik/main/website/docs/install-config/upgrade.mdx",
"https://raw.githubusercontent.com/goauthentik/authentik/main/website/docs/releases/2026/v2026.5.md",
]
ctx = ssl._create_unverified_context()
for url in urls:
print(f"--- {url} ---")
try:
text = urlopen(url, timeout=20, context=ctx).read().decode("utf-8", "replace")
lines = text.splitlines()
for i, line in enumerate(lines):
if any(term in line.lower() for term in (
"skip", "sequential", "major", "2023.10", "2025.12",
"2026.2", "upgrade path", "backup"
)):
lo, hi = max(0, i-2), min(len(lines), i+3)
print(f"{i+1}: " + "\n".join(lines[lo:hi]))
except Exception as exc:
print(type(exc).__name__, exc)
PYRepository: SpecterOps/BloodHound
Length of output: 7539
🌐 Web query:
site:docs.goauthentik.io/install-config/upgrade authentik skip versions sequential upgrade
💡 Result:
Authentik does not support skipping versions during an upgrade. Official documentation explicitly states that upgrades must follow the sequence of major releases and that you should not skip directly from an older major version to the most recent one [1]. To perform a safe upgrade, you must follow these steps: 1. Within each major.minor version, always upgrade to the latest minor version (e.g.,.x) before moving to the next major version [1]. 2. For example, if you are currently running version 2025.2.1, the upgrade path would be to upgrade to the latest 2025.2.x, then to the latest 2025.4.x, and finally to the latest 2025.6.x [1]. 3. You should review the release notes for each specific version you are upgrading to, as they may contain breaking changes or special requirements [1]. 4. The version of the authentik server and all authentik outposts must match, so ensure all outposts are upgraded at the same time as the core authentik instance [1]. Because downgrading is not supported, it is critical to back up your database before beginning the upgrade process so you can revert if an issue occurs [1].
Citations:
🌐 Web query:
site:github.com/goauthentik/authentik 2023.10.7 2026.5 database migration upgrade
💡 Result:
Upgrading from Authentik version 2023.10.7 to 2026.5 cannot be done directly [1][2][3]. Authentik strictly requires sequential upgrades by major version [1][2]. Skipping major versions often leads to failed database migrations, partial updates, or database corruption [3][4]. To upgrade from 2023.10.7 to 2026.5, you must upgrade through each intermediate major release [1][2]. You should also ensure you are on the latest minor release for each major version before moving to the next [1]. General upgrade process: 1. Always back up your PostgreSQL database before beginning [1]. 2. Upgrade to the latest minor version of each sequential major release [1]. For example: 2023.10.7 -> [2024.x] -> [2025.x] -> 2026.5 [1][2][3]. 3. For each step, update your deployment (e.g., Docker Compose file or Helm chart) to the specific version [1][2]. 4. Verify that all components (e.g., server, workers, outposts) are running the same version [2][5]. If you have already attempted a direct upgrade and encountered errors such as migration inconsistencies or "column does not exist" errors, you may need to restore your database from the backup taken before the failed upgrade attempt [1][3][4]. If no backup is available, you may be required to manually fix the database schema or revert to the previous version and perform the correct sequential upgrade path [3][6]. Consult the official Authentik upgrade documentation for the most accurate, version-specific instructions [1][3].
Citations:
- 1: https://github.com/goauthentik/authentik/blob/9a974f14/website/docs/install-config/upgrade.mdx
- 2: https://github.com/goauthentik/authentik/blob/95413c94/website/docs/releases/2026/v2026.5.md
- 3: Migration authentik_core.0058_setup fails on upgrade from v2025.10.2 to v2026.5.0 goauthentik/authentik#22688
- 4: Prevent application start/migration if sequential upgrade path is skipped goauthentik/authentik#20836
- 5: Got error after oauth authorize: violates not-null constraint "session_id" goauthentik/authentik#8470
- 6: Migration 0056_user_roles fails/hangs after failed upgrade attempt from 2025.10 -> 2026.2 goauthentik/authentik#20667
Document a safe Authentik and PostgreSQL migration path.
If authentik-db contains data from 2023.10.7, setting both services to 2026.5 skips required sequential Authentik upgrades. This change also upgrades PostgreSQL from 13.2-alpine to 18-alpine and changes the volume mount path. Add backup and intermediate-version procedures, or document removal of the authentik-db volume as a development-only reset before starting 2026.5. (Authentik upgrade documentation)
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@docker-compose.dev.yml` at line 228, Document a safe migration procedure for
the Authentik and PostgreSQL version changes in the development compose
configuration, including database backup and required sequential Authentik
upgrades from 2023.10.7, or clearly describe removing the authentik-db volume as
a development-only reset before starting 2026.5. Reference the affected
Authentik image configuration and PostgreSQL volume mount path, and preserve the
warning that existing data must not be started directly on the new versions.
| - sso | ||
| - sso-only | ||
| image: docker.io/library/postgres:13.2-alpine | ||
| image: docker.io/library/postgres:18-alpine |
There was a problem hiding this comment.
🗄️ Data Integrity & Integration | 🟠 Major | 🏗️ Heavy lift
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
compose_file=docker-compose.dev.yml
db_container="$(docker compose -f "$compose_file" ps -q authentik-db 2>/dev/null || true)"
if [[ -z "$db_container" ]]; then
echo "authentik-db is not running; start the stack before inspecting the volume."
exit 1
fi
docker inspect "$db_container" \
--format '{{range .Mounts}}{{println .Name .Destination}}{{end}}'
docker compose -f "$compose_file" exec -T authentik-db sh -c '
echo "PGDATA=${PGDATA:-unset}"
find /var/lib/postgresql -maxdepth 4 -name PG_VERSION -print
'Repository: SpecterOps/BloodHound
Length of output: 234
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo '--- docker-compose.dev.yml database section ---'
sed -n '260,305p' docker-compose.dev.yml
echo '--- PostgreSQL image and volume references ---'
rg -n -C 3 'postgres:|authentik-db|/var/lib/postgresql' --glob '!node_modules' --glob '!dist' .
echo '--- repository status and recent file summary ---'
git status --short
git diff --stat -- docker-compose.dev.ymlRepository: SpecterOps/BloodHound
Length of output: 8802
🌐 Web query:
Docker Official Image postgres 18 PGDATA /var/lib/postgresql/18/docker volume mount migration old /var/lib/postgresql/data
💡 Result:
In the official PostgreSQL Docker image, starting with version 18, the default PGDATA environment variable has been changed to /var/lib/postgresql/18/docker, and the declared VOLUME has been moved to /var/lib/postgresql [1][2][3]. This change replaces the previous convention where PGDATA was located at /var/lib/postgresql/data and the VOLUME was defined at that same path [1][3]. Mounting your volume at /var/lib/postgresql/data (the old location) with PostgreSQL 18+ will result in the container ignoring your existing data, as it will look for data in the new /var/lib/postgresql/18/docker location [4]. Migration Steps: Because PostgreSQL data is not directly compatible between major versions, you cannot simply move the files and restart the container. The recommended path for migrating your data is as follows: 1. Backup: Perform a full export of your existing database using pg_dumpall while the old container (version 17 or below) is running [4][3]. 2. Update Configuration: Update your docker-compose.yml or docker run command to mount your volume at the new target directory: /var/lib/postgresql [1][4][5]. 3. Recreate Container: Remove the old container and volume, then start a new container with the postgres:18 image using the updated mount path [4][5]. 4. Restore: Import your backup (e.g., via psql -f backup.sql) into the new instance [6][4]. If you have pre-existing data that you specifically want to move to the new structure, you must adjust the folder structure on your host or within your volume to place all database files into a 18/docker subdirectory before mounting the volume to /var/lib/postgresql [1][7][3]. However, since PostgreSQL major upgrades require a version-specific upgrade process (like pg_upgrade), a backup and restore is the standard and safest approach [4]. The new structure (/var/lib/postgresql as the volume mount and /var/lib/postgresql/18/docker as PGDATA) is intended to support faster upgrades between major versions by allowing the use of pg_upgrade --link when multiple versions are mounted under the same parent directory [1][8][3].
Citations:
- 1: https://hub.docker.com/_/postgres
- 2: https://github.com/docker-library/postgres/blob/master/18/bookworm/Dockerfile
- 3: https://github.com/docker-library/docs/blob/master/postgres/README.md
- 4: https://rdiachenko.com/posts/databases/postgresql/postgres-18-docker-silently-ignores-your-named-volume/
- 5: https://henrywithu.com/upgrade-postgresql-from-17-to-18-on-docker/
- 6: Postgres 18: VOLUME/PGDATA path change breaks existing mounts — docs/notes request docker-library/postgres#1370
- 7: Change
PGDATAin 18+ to/var/lib/postgresql/MAJOR/dockerdocker-library/postgres#1259 - 8: https://docs.docker.com/guides/postgresql/immediate-setup-and-data-persistence/
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo '--- previous compose definition ---'
git show HEAD^:docker-compose.dev.yml | sed -n '275,300p'
echo '--- current compose definition ---'
sed -n '279,297p' docker-compose.dev.yml
echo '--- relevant commit summary ---'
git log -5 --oneline -- docker-compose.dev.yml
echo '--- PostgreSQL 18 entrypoint defaults and initialization logic ---'
curl -fsSL https://raw.githubusercontent.com/docker-library/postgres/master/18/bookworm/docker-entrypoint.sh |
rg -n -C 5 'PGDATA|docker_setup_db|DATABASE_ALREADY_EXISTS|initdb'Repository: SpecterOps/BloodHound
Length of output: 9257
🏁 Script executed:
#!/bin/bash
set -euo pipefail
python3 - <<'PY'
from pathlib import Path
old_mount = Path("/var/lib/postgresql/data")
new_mount = Path("/var/lib/postgresql")
new_pgdata = new_mount / "18" / "docker"
volume = {
old_mount.relative_to(old_mount.parent): "old PostgreSQL cluster",
}
print(f"old cluster path in the reused volume: {old_mount}")
print(f"PostgreSQL 18 cluster path in the reused volume: {new_pgdata}")
print(f"same path: {old_mount == new_pgdata}")
print(f"old cluster is outside new PGDATA: {old_mount != new_pgdata}")
PYRepository: SpecterOps/BloodHound
Length of output: 359
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo '--- PostgreSQL 18 old-data detection and failure path ---'
curl -fsSL https://raw.githubusercontent.com/docker-library/postgres/master/18/bookworm/docker-entrypoint.sh |
sed -n '235,275p;338,366p'
echo '--- PostgreSQL 18 image PGDATA and volume declarations ---'
curl -fsSL https://raw.githubusercontent.com/docker-library/postgres/master/18/bookworm/Dockerfile |
rg -n -C 4 'PGDATA|VOLUME'
echo '--- PostgreSQL 13 image defaults for comparison ---'
curl -fsSL https://raw.githubusercontent.com/docker-library/postgres/13.2/alpine/Dockerfile |
rg -n -C 4 'PGDATA|VOLUME'Repository: SpecterOps/BloodHound
Length of output: 3890
🏁 Script executed:
#!/bin/bash
set -euo pipefail
python3 - <<'PY'
# Model the relevant paths only. This does not start containers or execute
# repository code.
old_cluster = "/var/lib/postgresql/data"
new_pgdata = "/var/lib/postgresql/18/docker"
old_database_candidates = [
"/var/lib/postgresql",
"/var/lib/postgresql/data",
"/var/lib/postgresql/*/docker",
]
print("old cluster matches PostgreSQL 18 legacy candidate:",
old_cluster in old_database_candidates)
print("old cluster equals PostgreSQL 18 PGDATA:",
old_cluster == new_pgdata)
print("PostgreSQL 18 requires a major-version migration:",
"13" != "18")
PYRepository: SpecterOps/BloodHound
Length of output: 318
🏁 Script executed:
#!/bin/bash
set -euo pipefail
entrypoint_url=https://raw.githubusercontent.com/docker-library/postgres/18/alpine/docker-entrypoint.sh
echo '--- PostgreSQL 18 Alpine old-data error ---'
curl -fsSL "$entrypoint_url" |
rg -n -C 8 'docker_error_old_databases|OLD_DATABASES|unused mount/volume'
echo '--- PostgreSQL 18 Alpine defaults ---'
curl -fsSL https://raw.githubusercontent.com/docker-library/postgres/18/alpine/Dockerfile |
rg -n -C 3 'PGDATA|VOLUME'Repository: SpecterOps/BloodHound
Length of output: 252
Migrate the existing authentik-db volume before switching to PostgreSQL 18.
The previous configuration stored the PostgreSQL 13 cluster at /var/lib/postgresql/data. PostgreSQL 18 expects /var/lib/postgresql/18/docker and does not perform a major-version migration. Add a documented pg_dumpall/restore procedure or an explicit destructive volume reset.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@docker-compose.dev.yml` at line 283, Update the PostgreSQL image change for
the existing authentik-db volume by documenting either a pg_dumpall/restore
migration from the PostgreSQL 13 data directory to PostgreSQL 18’s
/var/lib/postgresql/18/docker path, or an explicit destructive volume reset
procedure. Ensure the documentation clearly tells developers how to handle the
existing volume before starting the new image.
| profiles: | ||
| - sso | ||
| - sso-only | ||
| image: docker.io/library/postgres:13.2-alpine |
|
Note GitHub couldn't provide a complete incremental comparison for this pull request, so CodeRabbit is performing a full review instead. This review may take a little longer. |
|
Note GitHub couldn't provide a complete incremental comparison for this pull request, so CodeRabbit is performing a full review instead. This review may take a little longer. |
Description
Bumps authentik and brings it in line with BHE
Describe your changes in detail
Motivation and Context
Resolves BED-8628
Why is this change required? What problem does it solve?
How Has This Been Tested?
Please describe in detail how you tested your changes.
Include details of your testing environment, and the tests you ran to
see how your change affects other areas of the code, etc.
Screenshots (optional):
Types of changes
Checklist:
Summary by CodeRabbit