Testing from a fork

A ct/ script loads two things: the engine from core and its install script from the repository it belongs to. The two are resolved independently, so you can test a script branch against the released engine, an engine branch against released scripts, or both together.

core/build.func implements this. Source origin describes the resolution in detail.

Fork and branchCopy Anchor Link

Fork the repository that owns the change: DevScripts for a new script, ProxmoxVE for a fix.

git clone https://github.com/YOUR_USERNAME/DevScripts
cd DevScripts
git switch -c add-myapp

Do not edit URLs inside a script to point it at your fork. The variables above exist so the files you commit are identical to the files you tested.

From a pushed branchCopy Anchor Link

This is what a reviewer does, and what the "PR test command" comment on your pull request shows. Run it in the Proxmox VE shell or on an Incus host:

export COMMUNITY_SCRIPTS_URL=https://raw.githubusercontent.com/YOUR_USERNAME/DevScripts/add-myapp
bash -c "$(curl -fsSL "$COMMUNITY_SCRIPTS_URL/ct/myapp.sh")"

Both lines are needed. With bash -c "$(curl ...)" there is no file on disk the engine could derive the script repository from. Without COMMUNITY_SCRIPTS_URL you would run the ct/ script from your branch and the install script from the default repository's main.

The container remembers where it came from: its update command pulls ct/myapp.sh from the same COMMUNITY_SCRIPTS_URL. So update inside a container built this way tests the update_script of your branch.

From a local checkoutCopy Anchor Link

Copy or clone your fork onto the host and run the file directly:

git clone https://github.com/YOUR_USERNAME/DevScripts
cd DevScripts
git switch add-myapp
bash ct/myapp.sh

The engine finds the repository root by walking up from the script to the directory that contains ct/ and install/, and reads install/myapp-install.sh from there. Uncommitted changes are included, which makes this the fastest loop while you are still writing.

Two things to know:

• The engine itself still comes from core main unless a core checkout is found (next section).
• If git is installed and a local core checkout was found, the engine sets COMMUNITY_SCRIPTS_URL from the checkout's origin remote and current branch (GitHub remotes only). Without a core checkout the default repository URL is used. That URL is what the container's update command uses later, so push the branch before you test update inside the container.

With a core branchCopy Anchor Link

Local, with both checkouts side by side:

git clone https://github.com/YOUR_USERNAME/core
git clone https://github.com/YOUR_USERNAME/DevScripts
cd DevScripts
bash ct/myapp.sh

The second line of every ct/ script looks for ../../core/core/build.func relative to itself, which is a core directory next to the script repository. Set COMMUNITY_SCRIPTS_CORE_DIR if your core checkout is somewhere else.

Remote, by adding the engine URL:

export COMMUNITY_SCRIPTS_URL=https://raw.githubusercontent.com/YOUR_USERNAME/DevScripts/add-myapp
export COMMUNITY_SCRIPTS_CORE_URL=https://raw.githubusercontent.com/YOUR_USERNAME/core/my-core-branch
bash -c "$(curl -fsSL "$COMMUNITY_SCRIPTS_URL/ct/myapp.sh")"

core also ships a small runner, tools/run.sh, that sets both variables from its arguments and then runs the script. Its arguments are the script base, the script path and, optionally, the core base:

curl -fsSL https://raw.githubusercontent.com/community-scripts/core/main/tools/run.sh |
  bash -s -- https://raw.githubusercontent.com/YOUR_USERNAME/DevScripts/add-myapp ct/myapp.sh

Useful while testingCopy Anchor Link

dev_mode takes a comma-separated list of flags. Three are worth knowing for script work:

export COMMUNITY_SCRIPTS_URL=https://raw.githubusercontent.com/YOUR_USERNAME/DevScripts/add-myapp
dev_mode=net,keep bash -c "$(curl -fsSL "$COMMUNITY_SCRIPTS_URL/ct/myapp.sh")"

Dev mode lists all flags.

To build without the menu, as the automated test does, set mode=default:

export COMMUNITY_SCRIPTS_URL=https://raw.githubusercontent.com/YOUR_USERNAME/DevScripts/add-myapp
mode=default bash -c "$(curl -fsSL "$COMMUNITY_SCRIPTS_URL/ct/myapp.sh")"

If the install stops at a prompt in that mode, the automated test will fail at the same place. See Coding rules for how to make a prompt answerable.

What to test before opening the pull requestCopy Anchor Link

1. A fresh install with the default settings.
2. The address the script prints at the end answers in a browser.
3. update inside the container, right after the install. It must report that nothing is to do, or update cleanly.
4. If you changed update_script of an existing script: install from main, then update with your branch, as a user who installed before your change would. The container's /usr/bin/update carries the URL it was built from in an export COMMUNITY_SCRIPTS_URL= line. Point that line at your branch inside the container and run update; this is what the automated upgrade test does:

sed -i -E 's#^export COMMUNITY_SCRIPTS_URL=.*#export COMMUNITY_SCRIPTS_URL="https://raw.githubusercontent.com/YOUR_USERNAME/ProxmoxVE/fix-myapp"#' /usr/bin/update
update

The container keeps pulling from your branch afterwards, so use a throwaway container for this.