RFC: Make the ProxmoxVE URLs "relocatable" with an environment variable

[cricalix]

The current contributing guide branch has documentation that indicates the way to develop against the repo is to

• fork,
• branch,
• update all the URLs to refer to the forked repository,
• do development and testing,
• and then switch all the URLs back.

I'd like to propose a (small?) change to this approach; use a variable on all of the source calls in ct/*.sh, plus appropriate changes in build.func and other scripts. This would make the development process require zero changes to the shell scripts; just set an environment variable to change the base of the URL and away you go.

Benefits

• Shorter development loop if you use file:/// URLs with curl; no commit + push for every iteration
• Easier to try someone's fork
• Less mucking around with URLs in files, which reduces room for mistakes

For example,

Default

~/Source/ProxmoxVE$ bash ct/lidarr.sh
FIGlet or the slant font is missing. Installing...
Unsupported operating system.
Using https://raw.githubusercontent.com/community-scripts/ProxmoxVE/main as source of truth
  🖥  Operating System: debian
  🌟  Version: 12
  📦  Container Type: Unprivileged
  💾  Disk Size: 4GB
  🧠  CPU Cores: 2
  🛠  RAM Size: 1024MB
  🆔  Container ID: 
  🚀  Creating a Lidarr LXC using the above default settings

Remote by not setting the variable correctly

Defaults to the URL base in the script.

~/Source/ProxmoxVE$ CSCRIPTS_BASE_URL= bash ct/lidarr.sh
FIGlet or the slant font is missing. Installing...
Unsupported operating system.
Using https://raw.githubusercontent.com/community-scripts/ProxmoxVE/main as source of truth
  🖥  Operating System: debian
  🌟  Version: 12
  📦  Container Type: Unprivileged
  💾  Disk Size: 4GB
  🧠  CPU Cores: 2
  🛠  RAM Size: 1024MB
  🆔  Container ID: 
  🚀  Creating a Lidarr LXC using the above default settings

Forked repository

~/Source/ProxmoxVE$ CSCRIPTS_BASE_URL=https://raw.githubusercontent.com/cricalix/ProxmoxVE/main bash ct/lidarr.sh
FIGlet or the slant font is missing. Installing...
Unsupported operating system.
Using https://raw.githubusercontent.com/cricalix/ProxmoxVE/main as source of truth
  🖥  Operating System: debian
  🌟  Version: 12
  📦  Container Type: Unprivileged
  💾  Disk Size: 4GB
  🧠  CPU Cores: 2
  🛠  RAM Size: 1024MB
  🆔  Container ID: 
  🚀  Creating a Lidarr LXC using the above default settings

Local checkout

On my local checkout, I modified the echo_default function to add a word to the Container Type output; it's not pushed, so it doesn't show in the previous examples.

~/Source/ProxmoxVE$ CSCRIPTS_BASE_URL=file://$HOME/Source/ProxmoxVE bash ct/lidarr.sh
FIGlet or the slant font is missing. Installing...
Unsupported operating system.
Using file:///home/cricalix/Source/ProxmoxVE as source of truth
  🖥  Operating System: debian
  🌟  Version: 12
  📦  Container Type: Unprivileged (WOOHOO)
  💾  Disk Size: 4GB
  🧠  CPU Cores: 2
  🛠  RAM Size: 1024MB
  🆔  Container ID: 
  🚀  Creating a Lidarr LXC using the above default settings

The change for all the ct scripts looks like

 #!/usr/bin/env bash
-source <(curl -s https://raw.githubusercontent.com/community-scripts/ProxmoxVE/main/misc/build.func)
+: "${CSCRIPTS_BASE_URL:=https://raw.githubusercontent.com/community-scripts/ProxmoxVE/main}"
+source <(curl -s "${CSCRIPTS_BASE_URL}/misc/build.func")

The := syntax is "if the variable is null or unset, set it", similar (but not equal) to "${var-default}". The ": ${VAR...}" syntax is a bashism for triggering the expansion and assignment, and it always succeeds.

Some similar changes are needed in build.func, and possibly elsewhere - I haven't looked at everything yet.

This would conflict with the PR that adds actions to check file content for header lines on the right line number, but it'd not be hard to tune those checks. A check could be added to ensure the variable is present, and set to the expected community scripts URL.

I'm willing to put up a PR for this change, potentially after the documentation branch and the context-check PR are committed (and I'd update other files as appropriate).

[michelroegl-brunner]

You could make a PR against the develop branch so we can have a look. I find this idea very interesting. No need to wait for the Contributing or Shell check PR, we can changes those if need be.

[cricalix]

#1211 is a draft PR to support a discussion.