djpbessems/Kubernetes.K3s.installLog
1
1
Fork 0
Code Pull Requests 10 Actions Activity

Update ghcr.io/cerede2000/explorer Docker tag to v3.6.1 - autoclosed #55

Closed
srv.renovate wants to merge 1 commits from renovate/ghcr.io-cerede2000-explorer-3.x into master
pull from: renovate/ghcr.io-cerede2000-explorer-3.x
merge into: :master
Conversation 0 Commits 1 Files Changed 1
+1 -1
srv.renovate commented 2026-09-15 12:02:11 +00:00
Collaborator
Copy Link
Copy Source

This PR contains the following updates:

Package Update Change
ghcr.io/cerede2000/explorer minor 3.5.0-lean → 3.6.1-lean

Release Notes

cerede2000/NextExplorer (ghcr.io/cerede2000/explorer)

v3.6.1: — app.db gives back its space, and the indexes move to /cache

Compare Source

app.db gives back the space it frees

SQLite keeps what a deletion frees inside the file. An installation reported an app.db of 2,159 MB holding 160 MB of data — 2,000 MB of free pages, copied into every backup of /config. After upgrading to this release, the same app.db is 434 KB.

  • Once, at the first start, a database created by an earlier release is rewritten so that its free space can be handed back from then on. The log says how large it was before and after. On an SSD it took seconds for a 2 GB file.
  • Every hour after that, free space is handed back once more than 16 MB of it has built up, a little at a time, so the server keeps answering while it runs.
  • The write-ahead log (app.db-wal) is cut back to 64 MB after a checkpoint, instead of staying at its largest size.

The search index and folder sizes live in /cache

They were most of app.db, and nothing like the rest of it: every row can be read again from the files, and they are rewritten all day long. They now live in /cache/index.db, next to the sessions, apart from the accounts, shares and settings that cannot be made again.

  • Carried over, not rebuilt. At the first start the existing index is copied into /cache/index.db as it is, then removed from app.db. The volumes are not read again for it.
  • Nothing is lost if the copy fails — no room in /cache, say. app.db keeps the index, the log says why, and the next start tries again; after three starts that all failed, the index is rebuilt from the files instead.
  • Only the indexes are written under /cache. Nothing from the accounts or settings passes through it, even during the move.
  • Each file has its own writer, so an indexing pass and a sign-in no longer wait on the same lock.

A link out of a volume is shown as a link

A symbolic link inside a volume that points outside it — releases 1.1.8 to 2.0.2 left app.db, app-config.json and extensions links in the old cache directory — was listed with the size and type of what it points at, on a row where renaming, deleting and opening all failed with "Resolved path is outside the configured volume root" or "Path not found". Nothing could be read through such a link, and nothing can now either; the row now says what it is, offers no action, and opening it explains where to remove it.

Smaller fixes

  • Everything that starts with the server used to open app.db at once, and each caller went on to open it again and run the migrations over it: four connections at every start. The database is opened once.
  • Refusals from the server with a generic code — access denied, not found, conflict, too many requests — are headed in your language, with the server's own sentence underneath. The browser console no longer fills with vue-i18n warnings for codes that have no translation.

Upgrading

  • Mount /cache persistently. It now holds the search index and folder sizes as well as thumbnails and sessions. Without a persistent mount, every new container reads the volumes again to rebuild them. It still needs no backup.
  • The first start takes a little longer on an installation with a large app.db: the one-time rewrite, and the copy of the index. The rewrite needs free temporary space about the size of the data app.db really holds; if there is not enough, the server starts anyway and tries again next time.
  • Going back to 3.6.0 after this start works, but 3.6.0 finds no index in app.db: search reads the folders as it goes, and folder sizes are measured again.
ghcr.io/cerede2000/explorer:3.6.1
ghcr.io/cerede2000/explorer:3.6.1-lean

v3.6.0: — Security fixes, the trash and file versions

Compare Source

Security fixes

Upgrade if you share folders, use access rules, or sign in through an identity provider. Each of these was found by the tests written for this release and reproduced before being fixed, and each fix is held by a test that fails without it.

  • A copy or a move could write outside the folder it was allowed into. The destination was authorized, then the item's new name was joined onto it as the request spelled it: ../name wrote into a parent the caller could only read, and from a share into the volume outside it. A new name now has to be a name, and without one the item keeps the name it has on disk.
  • A zip of a folder carried what nobody browsing it could see. A folder downloaded as a zip, downloaded through a share link, or compressed in place included the paths an access rule hides and a personal folder kept inside the volume — and, with this release, would have carried the trash and file versions kept in .nextexplorer. An archive now holds what a listing of the folder shows.
  • Compressing ignored a share that withholds downloads. A visitor could compress a file into a volume of their own and download the archive from there. Compressing now needs the right to download.
  • With AUTH_MODE=oidc, password setup and password sign-in still answered. On an instance nobody had signed in to yet, anyone who could reach the API could make themselves its administrator with a password. Both are refused unless password sign-in is enabled.
  • Two first-run setups sent together both created an administrator. Setups now run one at a time.
  • An OIDC sign-in did not check that userinfo described the person signing in. The claims were read from the session the browser arrived with — on a fresh sign-in, nobody — so userinfo's subject was compared with nothing. The claims now come from the ID token the library verified, and userinfo must name the same subject. The same change lets a sign-in go ahead on the ID token when userinfo is briefly down, and no longer refuses a second person signing in from a browser that held someone else's session.

Deleting goes to the trash first

Deleting a file or a folder moves it to a trash instead of removing it. Trash in the sidebar lists what was deleted, restores it where it was or into a folder you choose, restores part of a deleted folder, previews a text file read-only, and deletes for good. Items leave for good after a retention period, 30 days by default.

  • No copy. Each volume keeps its trash in a hidden .nextexplorer folder at its own root, and deleting is a rename on the same disk: a 40 GB folder goes to the trash as fast as a small file.
  • Said before, not after. An item that cannot go to the trash — on another disk mounted inside a volume, larger than the trash's limit, or a volume itself — is named in the delete dialog before anyone confirms, with the reason.
  • Share links. What goes to the trash stops being reachable through its links at once, and the dialog says so. Restoring asks whether the links come back as they were.
  • Crash-safe. Every step writes what it is about to do before it touches the disk; an interrupted delete, restore or purge is finished or undone at the next start.
  • Who sees what. Each person sees what they deleted, administrators see everything, and what a share-link visitor deletes goes to the share owner's trash.

Documentation: Trash

Earlier versions of a file come back

Saving over a file keeps what the save replaces — from the text editor, the editor opened through a share link, ONLYOFFICE and Collabora. Right-click a file → Versions, or Versions in its details: open an earlier version read-only, download it, restore it, restore it as a copy, put it over another file, name it, pin it, delete one, several or all.

  • No copy here either. The replaced content is moved into the same .nextexplorer folder, and counts against the same space as the trash.
  • One version per office editing session, not one per autosave: the document before the session, a save someone asked for, and at most one checkpoint every 10 minutes in a long session.
  • Thinned as they age: every version for 24 hours, then one per hour to 7 days, one per day to 30 days, one per week after, at most 50 per file. Pinned versions are exempt.
  • Inside the editors. ONLYOFFICE's History lists the versions and restores one; Collabora's File → Revision history opens the panel.
  • Shares have two new options, Show file versions and Allow downloading versions.

The office side is tested against the ONLYOFFICE callback, WOPI and the signed history payloads, not yet against a running Document Server or Collabora instance. Reports are welcome.

Documentation: File versions

An administrator can release a locked account

nxzai/NextExplorer#370. Five failed sign-ins lock an account for fifteen minutes, and until now only waiting, or editing the database, released it. Settings → User Management marks a locked account with the time it frees itself, its Security tab offers Unlock now, and the sign-in screen says how long is left.

A sign-in survives a provider whose discovery document is down

A 503, a maintenance page, a refused connection or a timeout on the provider's /.well-known/openid-configuration threw out of the callback and refused a sign-in that had already succeeded. It falls back to the ID token's claims now, as it already did when the userinfo endpoint failed.

A refused or missing path answers as one

A file deleted since the listing was drawn, a path climbing out of the volume, another account's personal folder reached through the volume: each was refused, nothing leaked, but as a 500 with a stack in the log. They answer 404, 400 and 403 now, across every route that takes a path.

Smaller fixes

  • The account menu, the only way to Settings and to Sign out, opens from the keyboard. Its toggle is a real button, announced as a disclosure rather than as a menu it is not.
  • A folder restored from the trash or extracted from an archive is searchable at once, instead of after the next indexing pass.
  • Changing a mode keeps the setuid, setgid and sticky bits the item had.
  • An owner or a group typed in the details panel and left unsaved is no longer applied to the next item the panel shows.
  • Assigning a volume to a user can no longer add it twice.
  • The thumbnail settings no longer offer to save before they have loaded, which could write the defaults over what was stored.
  • A refused save of the access rules says why.
  • The Create new button closes the menu it opened.
  • A share created with its history options keeps them; they were dropped at creation and only an edit applied them.
  • ONLYOFFICE reopens a document renamed from its title bar under its new name, and closing while an automatic save is on its way still sends the save on close.

Underneath

  • Coverage, where the data and the access are. The tests written before this release went to what loses data or opens access when it is wrong — uploads, copy and move, compressing, permissions, sign-in, OIDC, account changes, settings and the screens that edit them — and found the security fixes above on the way. The backend went from 84.4% to 86.4% of statements and from 73.2% to 75.5% of branches; the frontend from 75.0% to 84.1% of statements and from 61.3% to 71.9% of branches. The floors that fail a push rose with them.
  • The upgrade itself is tested from the databases earlier releases leave. Schemas from 1.1.7, 1.2.0, 2.1.1, 2.2.7, 3.0.0, 3.1.0 and 3.5.0 are rebuilt as those releases create them and upgraded: accounts, sign-in methods, favorites, shares, volumes and settings come through, a restart changes nothing, and a migration that fails half-way leaves the database as it was.
  • A browser journey now runs against the server the image runs: first setup, sign-out and sign-in by keyboard, upload, share, the trash and a version restore, all checked on disk.
  • Every client call is checked against a server route, every code change must carry a test in the same commit, and coverage floors fail a push that lowers them.
  • The HEIC thumbnail tests had never run in CI while reporting green; they run on the image's own base now, and each published image must decode the fixture.
  • What the tests found and this release does not fix is written down in TODO.md, with what it costs.

Upgrading

  • Two schema migrations, for the trash and for file versions. They run at start; going back to 3.5.0 afterwards is not supported — keep a copy of /config if you may.
  • The trash and file versions are on by default. The container user needs write access at the root of each volume, where .nextexplorer is created; without it nothing is lost — the delete dialog says the item cannot go to the trash and asks before deleting for good. Switch either off with TRASH_ENABLED=false or VERSIONS_ENABLED=false, or in Settings → Trash and versions.
  • Backups of your volumes include .nextexplorer/ unless you exclude it.
  • Shares with named people that already exist get Show file versions and Allow downloading versions switched on; links for anyone get neither.
  • With AUTH_MODE=oidc, the password setup and sign-in endpoints now answer 403. Nothing in the interface used them in that mode.
  • New optional variables: TRASH_ENABLED, TRASH_RETENTION_DAYS, TRASH_MAX_PERCENT, TRASH_MAX_SIZE, VERSIONS_ENABLED, VERSIONS_KEEP_ALL_HOURS, VERSIONS_HOURLY_DAYS, VERSIONS_DAILY_DAYS, VERSIONS_MAX_PER_FILE, VERSIONS_SESSION_CHECKPOINT_MINUTES.
ghcr.io/cerede2000/explorer:3.6.0
ghcr.io/cerede2000/explorer:3.6.0-lean

Configuration

📅 Schedule: (UTC)

  • Branch creation
    • At any time (no schedule defined)
  • Automerge
    • At any time (no schedule defined)

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

  • If you want to rebase/retry this PR, check this box

This PR has been generated by Mend Renovate CLI.

This PR contains the following updates: | Package | Update | Change | |---|---|---| | [ghcr.io/cerede2000/explorer](https://github.com/cerede2000/NextExplorer) | minor | `3.5.0-lean` → `3.6.1-lean` | --- ### Release Notes <details> <summary>cerede2000/NextExplorer (ghcr.io/cerede2000/explorer)</summary> ### [`v3.6.1`](https://github.com/cerede2000/NextExplorer/releases/tag/v3.6.1): — app.db gives back its space, and the indexes move to /cache [Compare Source](https://github.com/cerede2000/NextExplorer/compare/v3.6.0...v3.6.1) #### app.db gives back the space it frees SQLite keeps what a deletion frees inside the file. An installation reported an app.db of 2,159 MB holding 160 MB of data — 2,000 MB of free pages, copied into every backup of `/config`. After upgrading to this release, the same app.db is 434 KB. - **Once, at the first start**, a database created by an earlier release is rewritten so that its free space can be handed back from then on. The log says how large it was before and after. On an SSD it took seconds for a 2 GB file. - **Every hour** after that, free space is handed back once more than 16 MB of it has built up, a little at a time, so the server keeps answering while it runs. - **The write-ahead log** (`app.db-wal`) is cut back to 64 MB after a checkpoint, instead of staying at its largest size. #### The search index and folder sizes live in /cache They were most of app.db, and nothing like the rest of it: every row can be read again from the files, and they are rewritten all day long. They now live in `/cache/index.db`, next to the sessions, apart from the accounts, shares and settings that cannot be made again. - **Carried over, not rebuilt.** At the first start the existing index is copied into `/cache/index.db` as it is, then removed from app.db. The volumes are not read again for it. - **Nothing is lost if the copy fails** — no room in `/cache`, say. app.db keeps the index, the log says why, and the next start tries again; after three starts that all failed, the index is rebuilt from the files instead. - **Only the indexes are written under `/cache`.** Nothing from the accounts or settings passes through it, even during the move. - **Each file has its own writer**, so an indexing pass and a sign-in no longer wait on the same lock. #### A link out of a volume is shown as a link A symbolic link inside a volume that points outside it — releases 1.1.8 to 2.0.2 left `app.db`, `app-config.json` and `extensions` links in the old cache directory — was listed with the size and type of what it points at, on a row where renaming, deleting and opening all failed with "Resolved path is outside the configured volume root" or "Path not found". Nothing could be read through such a link, and nothing can now either; the row now says what it is, offers no action, and opening it explains where to remove it. #### Smaller fixes - Everything that starts with the server used to open app.db at once, and each caller went on to open it again and run the migrations over it: four connections at every start. The database is opened once. - Refusals from the server with a generic code — access denied, not found, conflict, too many requests — are headed in your language, with the server's own sentence underneath. The browser console no longer fills with vue-i18n warnings for codes that have no translation. #### Upgrading - **Mount `/cache` persistently.** It now holds the search index and folder sizes as well as thumbnails and sessions. Without a persistent mount, every new container reads the volumes again to rebuild them. It still needs no backup. - **The first start takes a little longer** on an installation with a large app.db: the one-time rewrite, and the copy of the index. The rewrite needs free temporary space about the size of the data app.db really holds; if there is not enough, the server starts anyway and tries again next time. - **Going back to 3.6.0** after this start works, but 3.6.0 finds no index in app.db: search reads the folders as it goes, and folder sizes are measured again. ``` ghcr.io/cerede2000/explorer:3.6.1 ghcr.io/cerede2000/explorer:3.6.1-lean ``` ### [`v3.6.0`](https://github.com/cerede2000/NextExplorer/releases/tag/v3.6.0): — Security fixes, the trash and file versions [Compare Source](https://github.com/cerede2000/NextExplorer/compare/v3.5.0...v3.6.0) #### Security fixes **Upgrade if you share folders, use access rules, or sign in through an identity provider.** Each of these was found by the tests written for this release and reproduced before being fixed, and each fix is held by a test that fails without it. - **A copy or a move could write outside the folder it was allowed into.** The destination was authorized, then the item's new name was joined onto it as the request spelled it: `../name` wrote into a parent the caller could only read, and from a share into the volume outside it. A new name now has to be a name, and without one the item keeps the name it has on disk. - **A zip of a folder carried what nobody browsing it could see.** A folder downloaded as a zip, downloaded through a share link, or compressed in place included the paths an access rule hides and a personal folder kept inside the volume — and, with this release, would have carried the trash and file versions kept in `.nextexplorer`. An archive now holds what a listing of the folder shows. - **Compressing ignored a share that withholds downloads.** A visitor could compress a file into a volume of their own and download the archive from there. Compressing now needs the right to download. - **With `AUTH_MODE=oidc`, password setup and password sign-in still answered.** On an instance nobody had signed in to yet, anyone who could reach the API could make themselves its administrator with a password. Both are refused unless password sign-in is enabled. - **Two first-run setups sent together both created an administrator.** Setups now run one at a time. - **An OIDC sign-in did not check that userinfo described the person signing in.** The claims were read from the session the browser arrived with — on a fresh sign-in, nobody — so userinfo's subject was compared with nothing. The claims now come from the ID token the library verified, and userinfo must name the same subject. The same change lets a sign-in go ahead on the ID token when userinfo is briefly down, and no longer refuses a second person signing in from a browser that held someone else's session. #### Deleting goes to the trash first Deleting a file or a folder moves it to a trash instead of removing it. **Trash** in the sidebar lists what was deleted, restores it where it was or into a folder you choose, restores part of a deleted folder, previews a text file read-only, and deletes for good. Items leave for good after a retention period, 30 days by default. - **No copy.** Each volume keeps its trash in a hidden `.nextexplorer` folder at its own root, and deleting is a rename on the same disk: a 40 GB folder goes to the trash as fast as a small file. - **Said before, not after.** An item that cannot go to the trash — on another disk mounted inside a volume, larger than the trash's limit, or a volume itself — is named in the delete dialog before anyone confirms, with the reason. - **Share links.** What goes to the trash stops being reachable through its links at once, and the dialog says so. Restoring asks whether the links come back as they were. - **Crash-safe.** Every step writes what it is about to do before it touches the disk; an interrupted delete, restore or purge is finished or undone at the next start. - **Who sees what.** Each person sees what they deleted, administrators see everything, and what a share-link visitor deletes goes to the share owner's trash. Documentation: [Trash](https://cerede2000.github.io/NextExplorer/admin/trash) #### Earlier versions of a file come back Saving over a file keeps what the save replaces — from the text editor, the editor opened through a share link, ONLYOFFICE and Collabora. Right-click a file → **Versions**, or **Versions** in its details: open an earlier version read-only, download it, restore it, restore it as a copy, put it over another file, name it, pin it, delete one, several or all. - **No copy here either.** The replaced content is moved into the same `.nextexplorer` folder, and counts against the same space as the trash. - **One version per office editing session**, not one per autosave: the document before the session, a save someone asked for, and at most one checkpoint every 10 minutes in a long session. - **Thinned as they age**: every version for 24 hours, then one per hour to 7 days, one per day to 30 days, one per week after, at most 50 per file. Pinned versions are exempt. - **Inside the editors.** ONLYOFFICE's History lists the versions and restores one; Collabora's File → Revision history opens the panel. - **Shares** have two new options, *Show file versions* and *Allow downloading versions*. The office side is tested against the ONLYOFFICE callback, WOPI and the signed history payloads, not yet against a running Document Server or Collabora instance. Reports are welcome. Documentation: [File versions](https://cerede2000.github.io/NextExplorer/admin/versions) #### An administrator can release a locked account [nxzai/NextExplorer#370](https://github.com/nxzai/NextExplorer/issues/370). Five failed sign-ins lock an account for fifteen minutes, and until now only waiting, or editing the database, released it. **Settings → User Management** marks a locked account with the time it frees itself, its **Security** tab offers **Unlock now**, and the sign-in screen says how long is left. #### A sign-in survives a provider whose discovery document is down A 503, a maintenance page, a refused connection or a timeout on the provider's `/.well-known/openid-configuration` threw out of the callback and refused a sign-in that had already succeeded. It falls back to the ID token's claims now, as it already did when the userinfo endpoint failed. #### A refused or missing path answers as one A file deleted since the listing was drawn, a path climbing out of the volume, another account's personal folder reached through the volume: each was refused, nothing leaked, but as a 500 with a stack in the log. They answer 404, 400 and 403 now, across every route that takes a path. #### Smaller fixes - The account menu, the only way to Settings and to Sign out, opens from the keyboard. Its toggle is a real button, announced as a disclosure rather than as a menu it is not. - A folder restored from the trash or extracted from an archive is searchable at once, instead of after the next indexing pass. - Changing a mode keeps the setuid, setgid and sticky bits the item had. - An owner or a group typed in the details panel and left unsaved is no longer applied to the next item the panel shows. - Assigning a volume to a user can no longer add it twice. - The thumbnail settings no longer offer to save before they have loaded, which could write the defaults over what was stored. - A refused save of the access rules says why. - The **Create new** button closes the menu it opened. - A share created with its history options keeps them; they were dropped at creation and only an edit applied them. - ONLYOFFICE reopens a document renamed from its title bar under its new name, and closing while an automatic save is on its way still sends the save on close. #### Underneath - **Coverage, where the data and the access are.** The tests written before this release went to what loses data or opens access when it is wrong — uploads, copy and move, compressing, permissions, sign-in, OIDC, account changes, settings and the screens that edit them — and found the security fixes above on the way. The backend went from 84.4% to 86.4% of statements and from 73.2% to 75.5% of branches; the frontend from 75.0% to 84.1% of statements and from 61.3% to 71.9% of branches. The floors that fail a push rose with them. - **The upgrade itself is tested from the databases earlier releases leave.** Schemas from 1.1.7, 1.2.0, 2.1.1, 2.2.7, 3.0.0, 3.1.0 and 3.5.0 are rebuilt as those releases create them and upgraded: accounts, sign-in methods, favorites, shares, volumes and settings come through, a restart changes nothing, and a migration that fails half-way leaves the database as it was. - A browser journey now runs against the server the image runs: first setup, sign-out and sign-in by keyboard, upload, share, the trash and a version restore, all checked on disk. - Every client call is checked against a server route, every code change must carry a test in the same commit, and coverage floors fail a push that lowers them. - The HEIC thumbnail tests had never run in CI while reporting green; they run on the image's own base now, and each published image must decode the fixture. - What the tests found and this release does not fix is written down in `TODO.md`, with what it costs. #### Upgrading - **Two schema migrations**, for the trash and for file versions. They run at start; going back to 3.5.0 afterwards is not supported — keep a copy of `/config` if you may. - **The trash and file versions are on by default.** The container user needs write access at the root of each volume, where `.nextexplorer` is created; without it nothing is lost — the delete dialog says the item cannot go to the trash and asks before deleting for good. Switch either off with `TRASH_ENABLED=false` or `VERSIONS_ENABLED=false`, or in **Settings → Trash and versions**. - **Backups** of your volumes include `.nextexplorer/` unless you exclude it. - **Shares with named people** that already exist get *Show file versions* and *Allow downloading versions* switched on; links for anyone get neither. - **With `AUTH_MODE=oidc`**, the password setup and sign-in endpoints now answer 403. Nothing in the interface used them in that mode. - New optional variables: `TRASH_ENABLED`, `TRASH_RETENTION_DAYS`, `TRASH_MAX_PERCENT`, `TRASH_MAX_SIZE`, `VERSIONS_ENABLED`, `VERSIONS_KEEP_ALL_HOURS`, `VERSIONS_HOURLY_DAYS`, `VERSIONS_DAILY_DAYS`, `VERSIONS_MAX_PER_FILE`, `VERSIONS_SESSION_CHECKPOINT_MINUTES`. ``` ghcr.io/cerede2000/explorer:3.6.0 ghcr.io/cerede2000/explorer:3.6.0-lean ``` </details> --- ### Configuration 📅 **Schedule**: (UTC) - Branch creation - At any time (no schedule defined) - Automerge - At any time (no schedule defined) 🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied. ♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox. 🔕 **Ignore**: Close this PR and you won't be reminded about this update again. --- - [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check this box --- This PR has been generated by [Mend Renovate CLI](https://github.com/renovatebot/renovate). <!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiI0NC45My4wIiwidXBkYXRlZEluVmVyIjoiNDQuOTMuMCIsInRhcmdldEJyYW5jaCI6Im1hc3RlciIsImxhYmVscyI6W119-->
djpbessems was assigned by srv.renovate 2026-09-15 12:02:13 +00:00
srv.renovate added 1 commit 2026-09-16 12:01:22 +00:00
Update ghcr.io/cerede2000/explorer Docker tag to v3.6.1 0ca95872a0
srv.renovate force-pushed renovate/ghcr.io-cerede2000-explorer-3.x from 74479cdc6b to 0ca95872a0 2026-09-16 12:01:22 +00:00 Compare
srv.renovate changed title from Update ghcr.io/cerede2000/explorer Docker tag to v3.6.0 to Update ghcr.io/cerede2000/explorer Docker tag to v3.6.1 2026-09-16 12:01:22 +00:00
srv.renovate changed title from Update ghcr.io/cerede2000/explorer Docker tag to v3.6.1 to Update ghcr.io/cerede2000/explorer Docker tag to v3.6.1 - autoclosed 2026-09-16 23:41:18 +00:00
srv.renovate closed this pull request 2026-09-16 23:41:18 +00:00

Pull request closed

This pull request cannot be reopened because the branch was deleted.
Sign in to join this conversation.
Reviewers
No Reviewers
Labels
No items
No labels
Milestone
No items
No Milestone
Assignees
Clear assignees
srv.renovate (Renovate Bot) djpbessems (Danny Bessems)
No Assignees djpbessems
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: djpbessems/Kubernetes.K3s.installLog#55