Repository navigation
Conversation
…he flash On Unraid, /mnt itself is RAM. A path that is not on a mounted disk, pool or share (a typo such as /mnt/usr/appdata, or /mnt/user while the array is stopped) silently lands in RAM, and a stray file left in /mnt/user can stop the user shares from mounting at the next array start. GitPathGuard checks, immediately before any write, that the array is started, that the path is on a live mount below /mnt, and that no symlink leads out of it. createDirectory() creates missing levels one at a time and never creates a mount point or a share. - A tmpfs, ramfs or rootfs mount under /mnt does not count as a disk: Unassigned Devices can put a tmpfs over /mnt/disks, and a folder left there for an unplugged disk must not pass. - An exclusive share (Unraid 6.12+), where /mnt/user/<share> is a symlink to /mnt/<pool>/<share>, is followed to the pool when the pool is mounted. Any other symlink at the share level is refused. Nothing uses it yet; the git stack code in the following commits does. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_011iUWDG8wTp8MhsFDqNC4NL
Every git call for git-backed stacks goes through GitCommand::run(). It
ignores the system and global git config, never prompts, runs no repository
hooks, allows only the https and local-path transports, starts from an
empty environment so stray GIT_DIR or GIT_WORK_TREE values cannot redirect
it, passes arguments without a shell, and is stopped by GNU timeout after a
time limit.
git refuses a repository owned by another user ("dubious ownership"). A
clone can end up owned by nobody:users after Unraid's New Permissions tool,
and a repository on this server is often owned by the container that keeps
it. Each run trusts the folder it works in and any repository the caller
names, and nothing else, through a global config file that holds only those
safe.directory entries (git 2.47 ignores safe.directory given with -c when
it reads from a local repository).
ProcessRunner reports a command killed by a signal as 128 plus the signal
number, and counts it as timed out only when the time limit was reached.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011iUWDG8wTp8MhsFDqNC4NL
A git stack keeps its repository address, branch, compose file path and clone folder in git.json in the stack folder. Every value is checked when the settings are created and again on every load, since the file can be edited by hand or restored from a backup: - the address must be an https URL with no user name or password in it, or a repository path under /mnt; - the branch must pass git check-ref-format and cannot start with "-"; - the compose path must be a relative .yml/.yaml path that stays inside the repository and outside .git; - the clone folder must be under /mnt and carry the stack's clone id, so two stacks can never share one. A file with missing, extra or wrongly typed settings is reported, never partly used. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_011iUWDG8wTp8MhsFDqNC4NL
GitClone manages the clone behind one git stack. It clones only into a folder that does not exist yet (and removes only that folder if the clone fails), marks the clone with the stack's id, and before changing anything checks that the folder is still that marked clone of that repository. The clone is checked out detached at a commit and never committed to. Untracked files, such as data a container writes through a relative bind mount, are never removed or overwritten: there is no git clean and no forced checkout, and a checkout that would put a file where an untracked one is stops and changes nothing. A plain checkout refuses that by itself, so the whole repository is checked out (a sparse checkout overwrites untracked files silently). Ignored files need one more flag: git treats them as expendable and overwrites them by default, so every checkout passes --no-overwrite-ignore. A data folder listed in .gitignore is the usual layout, so this case matters most. Local edits to tracked files are listed, and a checkout is refused while there are any. Saving and discarding them is the next commit. A repository on this server is trusted by git even when another user owns it, so a stack can deploy from one a container keeps under appdata. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_011iUWDG8wTp8MhsFDqNC4NL
…ing them This is the only code that discards the user's own changes, so it is a step of its own. Local changes in the clone (edits, and commits made by hand) can be saved as a patch in the stack folder, and are discarded only after that. The patch is the only copy once they are discarded, so a short write (a full flash) stops the discard. Discarding is refused, before anything is saved, when an untracked or ignored file sits at a path tracked at the checked-out commit (a tracked file replaced by a folder of data, or a file removed from the index and then edited): "git reset --hard" would delete or overwrite it, and the patch would not hold it. Staged changes are unstaged first, because a staged new file (for example after "git add -A" swept up a container's ./data folder) is not listed as untracked, and the reset would delete it. isOnBranch() and lastCommitSharedWithBranch() tell a commit made by hand in the clone apart from a newer commit of the branch, so the patch can be taken against the right base. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_011iUWDG8wTp8MhsFDqNC4NL
A git stack is an indirect stack whose target is a plugin-managed clone, so anything the plugin writes into that folder would show up as a local change and could be lost to the next pull. For stacks with git.json, StackInfo now: - reads, creates and saves the plugin-managed override in the stack folder; - applies both overrides when composing: the repository's own (if it has one), then the managed one, so a repository override no longer hides the plugin's labels. An override file that does not exist is left out; - uses the stack folder's .env if there is one, so secrets can stay out of the repository, and otherwise a .env committed next to the compose file, for people who keep their settings versioned with the stack. The editor creates a new .env in the stack folder; - never uses default compose file discovery, so its files are always named. Ordinary stacks behave exactly as before. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_011iUWDG8wTp8MhsFDqNC4NL
GitDeployCheck runs `docker compose config` with the stack's real files, env file and profiles, and works on the JSON it prints; the plugin never parses YAML itself. A deploy is stopped, naming each problem, when: - compose reports an error, the file defines no services, or a variable used by the compose file is not set (a blank value can create state that outlives fixing it); - the repository's .env.example lists keys missing from the .env in use (key names only, never values); - an external network or volume does not exist; - a bind-mount source is under /mnt but not on a mounted disk, pool or share (Docker would create it in RAM), its share does not exist (a typo, or it would quietly become a new share), or it is outside /mnt and does not exist. Missing folders below an existing share, such as a new stack's appdata/newapp/config, are left for Docker to create and named in the deploy log. Sources inside the clone (relative paths such as ./data) are allowed; - a config or secret file, or a local build folder, does not exist; - a container name or published port is already taken by another stack or a plain container. Docker is run through DockerCommand (no shell, time limit). The tests use a scripted stand-in for the docker CLI. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_011iUWDG8wTp8MhsFDqNC4NL
GitStackState is git_state.json in the stack folder: the last commit that deployed successfully, and the commit whose deploy failed, if the last one did. It is written only when a deploy finishes, so the flash sees one small write per deploy. A broken file is reported, never guessed at, and the format follows the same change rules as git.json. The next commit, gitdeploy, reads and writes it. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_011iUWDG8wTp8MhsFDqNC4NL
`compose.sh -c gitdeploy` deploys a git stack under the stack's usual lock: 1. git_stack.php prepare fetches the branch (or takes a given commit), refuses if the clone has local changes (or saves them as a patch and discards them when asked), refuses if the compose file no longer exists at that commit, checks it out, and runs every pre-flight check. If any of that fails, the previous commit is put back and no container has been touched. 2. The images are pulled, then services with a build section are built, as steps of their own. If either fails, the previous commit is put back. 3. `up -d --remove-orphans` starts the stack from the new commit. On success the commit is recorded as deployed in git_state.json and superseded images are removed, as Update and auto-update do. On failure the commit is recorded as failed. A half-finished up is not rolled back, and the next deploy starts from the failed commit. Every answer from the git helper is checked: PHP notices go to stderr, the previous commit must be a full commit id, and a failure to read the compose files stops the deploy. If putting the previous commit back fails, the message says the clone is still at the new commit. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_011iUWDG8wTp8MhsFDqNC4NL
Plain "up -d" recreates a container only when its compose definition changed, so a commit that only edits a bind-mounted config file was checked out but never took effect. A new per-stack setting in git.json, recreateOnFolderChange (on by default), makes the deploy add --force-recreate when anything in the stack's folder changed since the previous commit. Recreate, not restart: a restart keeps a single-file mount on the old copy of the file. If the commits cannot be compared, the previous commit is put back and no container is changed, the same as a failed pull or build. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_011iUWDG8wTp8MhsFDqNC4NL
compose-git creates, deploys and looks after git stacks from the command line (scripts/compose-git): - add: clone a repository and make a new git stack from it; - convert: turn an existing stack into a git stack. Its folder, name, project name, .env and plugin override stay; the old compose file and indirect settings are moved into a dated backup folder, and a .env that sat next to an indirect stack's old compose file is copied in; - check: compare the deployed commit with the branch, changing nothing; - deploy: run compose.sh gitdeploy, with the stack's credential; - reclone: move the clone aside (never delete it: untracked data lives there) and clone again at the deployed commit, moving the old one back if the new clone fails; - status [--json]: what is deployed, failed and changed locally. Stacks are named by their exact folder, convert and reclone take compose.sh's lock for the stack, and the exit status is the result (0 ok, 1 failed, 2 usage, 3 check found a newer commit) so scripts and git hooks can use it. Cloning now also refuses, and removes the new clone, when the compose file is not on the branch. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_011iUWDG8wTp8MhsFDqNC4NL
How git stacks work, a quick start, and a step-by-step guide to moving an existing stack into git (including getting its files into a repository and keeping secrets out). Also: how to lay out repositories (every stack keeps its own clone, so keep a shared repository small and give big stacks their own), which .env is used, making folders writable for non-root containers, recreating on config changes, local changes and patches, failed deploys, the pre-flight checks, and the compose-git command reference. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_011iUWDG8wTp8MhsFDqNC4NL
…setting is on With Create Missing External Networks on, compose.sh creates a stack's missing `external: true` networks before up and update. A git deploy did not: its pre-flight check refused the stack over the missing network, so the same stack started by hand but would not deploy from git. With the setting on, the pre-flight check no longer counts a missing external network as a problem (external volumes are still checked), and gitdeploy creates the missing networks right before up. That is after every check, pull and build has passed, so a deploy that stops earlier creates nothing. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_011iUWDG8wTp8MhsFDqNC4NL
… checks The web UI prunes the plugin-managed override before every up; a git deploy did not. When a commit renames or removes a service, the override keeps an entry for it with labels only, and compose refuses the whole stack over a file the user did not write. Prune it after the checkout and before the checks, and log each service removed. This relies on #169: before it, pruneOrphanOverrideServices() never removed anything. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PnMScBowJk7yyfEwraTdgg
compose.sh kept its lock files in a fixed /var/run/compose.manager, which only root can create. The GitHub runner is not root, so every gitdeploy test failed at the lock with "Another operation is already in progress". The local test container runs as root, which hid it. The lock folder can now be set with COMPOSE_LOCK_DIR, the same way COMPOSE_LOCK_TIMEOUT already sets the wait. The default is unchanged. The gitdeploy tests point it at their temporary folder. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PnMScBowJk7yyfEwraTdgg
…s are taken The container-name and port checks took any failed docker command as "nothing is taken": a daemon that is not answering, or a timeout, let the deploy go on to "up", which would then find the clash after changing some containers. Now only "No such container" means the name is free. Any other failure, and output that is not JSON, is reported as a problem and stops the deploy before "up", like every other check. A container removed between "docker ps" and the bulk inspect is still fine: inspect prints the others and the removed one holds no port. The fake docker used by the tests can now be told to fail a command. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01NavH8cj9aU49Qs1pQPa1Qc
The port check compared the stack's published ports only with running containers of other stacks. Two services of the stack itself asking for the same host port passed it, and "up" then started one service and failed on the other, after the containers had changed. The ports are now also compared with each other, with the same address and protocol rules as against other containers. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01NavH8cj9aU49Qs1pQPa1Qc
…itten reclone cleared the deployed commit when the rewritten branch no longer held it. The next deploy then had nothing to compare the new commit with, so it ran a plain "up", and a container whose bind-mounted config changed in the rewrite kept the old file. The deployed commit now stays recorded. The next deploy finds it gone from the clone and recreates every container, which GitDeploy::upArguments already does for a commit that cannot be measured against. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01NavH8cj9aU49Qs1pQPa1Qc
The profiles, services and build caches of a git stack were compared with the repository's override only while that file existed. A commit that removed the override, and changed nothing else, left the caches looking fresh, so the plugin kept answering from a file that was no longer a compose input. When the override is missing, its folder's modification time is compared instead: removing a file updates the folder. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01NavH8cj9aU49Qs1pQPa1Qc
A container with a bind mount into the clone keeps the moved folder until it is recreated, and a rewritten branch leaves the new clone at its latest commit. Say both next to the reclone command. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01NavH8cj9aU49Qs1pQPa1Qc
Align documented requirements with the plugin's PHP 8 dependency. Remove obsolete patch scripts, assets, installer hooks, settings and action handling, while retaining the pre-7.0 Ace fallback and Git patch features. Add installer compatibility regression coverage for the minimum version and Ace fallback. Fixes #170.
Since #149 made --build opt-in, updating a stack whose image: is only built locally failed on pull access denied. Retry the pull with --ignore-buildable and add --build to up when the plain pull fails.
The git stacks guide gets an "Automatic deploys" section: the three choices, what "changes the stack" means in a shared repository, why a commit is held back (a failed deploy, local changes, a stack that is not running) and how it goes on, and the cron line. The web UI table and the command reference gain auto-deploy, resume and scheduled-check, and "No automatic deploys yet" leaves the limitations. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The checks a git deploy runs before up now return the problems they found, and prepare() still turns them into the error that stops the deploy. Nothing changes for a deploy. The next commit, a dry run of a deploy, lists the problems instead of stopping on them. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
A plain git status refreshes the index and writes it back, taking .git/index.lock while it does. The Sources tab and the scheduled check ask for a clone's local changes without the stack's lock, so a checkout in the clone at that moment (a deploy's, or putting the previous commit back after a failed check) could fail on "index.lock: File exists" and leave the clone at the wrong commit. git status --no-optional-locks reads without writing the index, which is what git documents for background status readers. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
PHP keeps what realpath() and file_exists() found for a while. After a checkout replaced the compose file with a symlink, a process that had already resolved the file's path got the old answer, and the check that the compose file stays inside the clone passed. A deploy runs its checks in a fresh process (git_stack.php), so it was not affected. The dry run in the next commits resolves the compose file before and after the checkout in one process, and its test found this. Every checkout now clears PHP's file cache. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
A dry run runs every check a deploy runs before it pulls the images, and stops there: fetch, check out the commit, run the checks, then check the commit from before out again. It also compares the compose configuration of the two commits, and says whether up would recreate every container. No container is started, stopped or recreated, nothing is pulled or built, and the stack's state is not changed. Like a deploy, it checks the commit out in the clone itself, so for as long as the checks run, a container reading a folder of the clone sees the tried commit's files. The configuration is compared as "docker compose config --no-interpolate --no-env-resolution" prints it: variables as written, not their values, so nothing from the .env or the env files is printed. When it cannot be read or compared, the dry run says why and still reports the checks. The checks prune the plugin's override as a deploy's do; the dry run puts the override back as it was, unless it was saved again meanwhile (from the Labels tab, say). Local changes in the clone stop the dry run, as they stop a deploy, and are kept. The dry run takes the stack's lock and is refused while another operation on the stack runs, and refused for a stack whose project name is not settled, as a deploy is. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Runs the dry run from the previous commit and prints what it found: which commit would be deployed (and the last one deployed successfully, when the clone holds another after a failed up), whether every check passed or what would stop the deploy, whether up would recreate every container, and how the compose configuration changes. The exit status is 0 when every check passed and 1 when one did not, so a script can try a commit before deploying it. A dry run does not pull images, so it says that a missing image or tag is found only by the deploy. --dry-run takes only --commit and --profile: the options for saving local changes and waiting for healthy containers mean nothing without a deploy, and are refused rather than ignored. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The scheduled check's lock, git-scheduled-check.lock, sits in the folder where each stack's lock is <project name>.lock. A stack named git-scheduled-check therefore had the pass's own lock as its stack lock: the pass already held it, so that stack always looked busy and was never checked. The pass's lock is now .git-scheduled-check.lock. A project name never starts with a dot, so no stack's lock can be that file. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The scheduled check compares one commit, the branch's head when it asked, and records that commit as handled. But it started the deploy without a commit, so the deploy fetched again and took whatever the branch's head was by then. If the branch moved from B to C in between, C was deployed while B was recorded: a failure of C before up was reported as B's, and the next pass could try C again despite the once-per-commit rule. The pass now passes the commit it compared to the deploy (compose.sh --git-commit). A newer commit is compared and handled by the next pass. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…ride The dry run kept a copy of the plugin's override from before its checks, and after them wrote that copy back if the override was still as the checks' prune left it. A save from the Labels tab after the copy was taken but before the prune was lost that way: the prune read the newer save (and, when it had nothing to remove, left it as it was), so the override still matched what the prune left, and the older copy was written over it. The prune now says what it read and what it wrote when it changed the override. The dry run puts back what the prune read, and only when the prune changed something and nothing saved the override since. A save before the prune is what the prune read, so it is kept. The dry run also now puts back the file the prune writes, the project override (getProjectOverridePath()). It used to read getOverridePath(), which on a stack with an indirect override is the indirect file, not the one the prune changed. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The dry run's documentation said nothing from the .env or the env files is printed. That holds for the configuration diff, which is read with --no-interpolate, but not for what the checks find: those are the deploy's own messages, read from the resolved configuration, so a missing folder or external volume whose path or name is built from a variable is named as it resolves. A deploy's log says the same. The docs, the --dry-run help and the code comment now say so, and keep the promise to the diff it holds for. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
… applies
The scheduled check decides to deploy a commit (automatic deploys set to
Deploy, no failed deploy, no local changes, the stack running) without
the stack's lock, since the deploy it starts must take that lock itself.
Things can change before the deploy gets it: a Stop or Down queued
meanwhile ran first, and the deploy then started the stack someone had
just stopped; or the stack was switched to Off or Notify while the check
asked the remote, and it was deployed anyway. And since the deploy now
gets the commit the check compared, a Pull and Redeploy (or a rollback)
that ran in between would be replaced by that commit, which may be older.
compose.sh gitdeploy takes a new --automatic-deploy-from option, which
the scheduled check passes with the deployed commit it compared from
("none" if none). Under the stack's lock, before fetching, git_stack.php
checks all of that again, and that the deployed commit is still the one
the check compared from (GitDeploy::assertAutomaticDeployStillApplies()).
When one no longer holds, nothing is changed and gitdeploy exits 75
(GIT_DEPLOY_EXIT_SKIPPED, EX_TEMPFAIL): no failed result is saved, the
background runner logs it without a failure notification, and the
scheduled check records the commit as not handled, so its next pass
decides again with what it finds then (and says so once, as for any
stopped stack). A clone or docker that cannot be asked is a skip too, as
it is for the scheduled check itself. A failed up that happens to exit 75
exits 1 instead, so it is never read as a skip.
The docker ps question moves to GitDeploy::hasRunningContainers(), and
the local-changes question to GitDeploy::localChanges(); the scheduled
check and the deploy both use them.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
feat(git): check git stacks on a schedule, deploy new commits, and try a deploy first (#138, part 4)
Three places read git.json as plain JSON on purpose, so a stack whose settings fail a check still counts: the cron rebuild, the Credentials tab's in-use scan and the deploy key sharing. Each calls json_decode on the file directly, which returns null for a file that starts with a byte order mark, while GitStackSettings::load() strips one. GitStackSettings::readAsPlainJson() reads the file the way load() does (byte order mark removed) without checking the settings. The next commits move the three readers onto it. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The cron rebuild decoded each git.json directly, so a file that starts with a byte order mark (saved by a Windows editor) read as no settings. If that stack was the only one asking for automatic checks, the rebuild dropped the scheduled git check, although the stack itself loads fine. Read it with GitStackSettings::readAsPlainJson(), which removes the mark. Found by Copilot on #172. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…s a byte order mark The Credentials tab's in-use scan decoded each git.json directly, so a file that starts with a byte order mark read as no settings. The stack then did not count as using its credential, and deleteCredential could delete a token or deploy key the stack still needs, although the stack itself loads fine. Read it with GitStackSettings::readAsPlainJson(), which removes the mark. Exec.php already loads GitStackSettings through GitStackWebActions. Found by Copilot on #172. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
… mark Deploy key sharing reads every git.json as plain JSON, to find which stacks of a repository use which key. It decoded the file directly, so a file that starts with a byte order mark could not be read: that stack was passed over, a new stack of the same repository did not get its key, and its key could be taken for unused and given to a new stack of another repository with the old "<stack> deploy key" name. Read it with GitStackSettings::readAsPlainJson(), which removes the mark. The same bug as the cron rebuild and Credentials tab fixes, in a third place. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The Credentials tab's in-use scan reads git.json as plain JSON, so a stack whose settings fail a check still counts. A file that is not JSON at all (a trailing comma from a hand edit) counted as using no credential, so its token or deploy key could be deleted. Once the typo was fixed, the stack named a credential that no longer existed. deleteCredential now refuses to delete a git credential while a git.json that cannot be read as JSON may name it: its text contains the credential's id, it cannot be read at all, or it holds NUL bytes (saved as UTF-16). The message names those stacks and where to see the error. Registry credentials are never in a git.json, so they are not held up, and neither is a git credential no broken file names. The Credentials tab now shows the message when a delete is refused or the request fails; it used to reload the list without a word. The message waits for the confirm dialog to close, as other dialogs in the plugin do. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…r is missing When the projects folder is on the array and the array is stopped, the folder is not there: the in-use scan finds no stacks, every credential looks unused, and deleteCredential deletes one a stack still needs. deleteCredential now refuses while the projects folder is missing and says to start the array. Found by the review of the previous commit. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
Both of Copilot's new findings (the byte order mark in |
fix(git): read git.json with a byte order mark everywhere
Use group roles for the five internal editor panels so Unraid's document-wide tabpanel selector only matches outer Docker panels. Preserve editor IDs, ARIA relationships, and class-based switching. Manually verified on Unraid 7.3.2: Docker Networks selection and all Compose editor tabs work.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This pull request introduces a new beta release of Compose Manager Plus, focusing on improved Git integration, updated licensing, and the removal of legacy UI patching for Unraid versions prior to 6.12. Key changes include comprehensive Git stack management features, a clarified and more restrictive licensing scope, and updated documentation and requirements reflecting these changes.
Major new features and improvements:
Git integration and automation:
Licensing and provenance:
LICENSE, clarifying that only original material by Nick Szittai (mstrhakr) is MIT-licensed, and that inherited or third-party code is excluded.README.mdto reflect the new licensing scope, provide links to licensing and provenance audits, and clarify redistribution limitations.Unraid version requirements and UI patching:
Documentation updates:
Plugin metadata and release:
2026.10.20.0925, updates download URLs to point to thedevbranch, and includes a detailed changelog for this release. [1] [2]These changes collectively modernize the plugin, streamline its compatibility, and offer powerful new capabilities for managing Compose stacks from Git repositories.