Create an unofficial iocage plugin

[Baenwort]

Does anyone have any advice on how to get the artifact to pull a particular branch of the repo and not the default branch?

This would really help in testing new builds of an artifact.

 

[Jurgen Segaert]

I've never tried it myself, but the iocage fetch command has a --branch option.

Code:

➜  ~ iocage fetch --help
Usage: iocage fetch [OPTIONS] [PROPS]...

  Fetch a version of FreeBSD for jail usage or a preconfigured plugin.

Options:
  -h, --http                      No-op flag for backwards compat
  -f, --file                      Use a local file directory for root-dir instead of HTTP
  -F, --files TEXT                Specify the files to fetch from the mirror.
  -s, --server TEXT               Server to fetch from.
  -g, --git_repository TEXT       Git repository to use to fetch plugin.
  -k, --keep_jail_on_failure      Keep jails on failure
  -u, --user TEXT                 The user to use.
  -p, --password TEXT             The password to use.
  -a, --auth TEXT                 Authentication method for HTTP fetching. Valid values: basic, digest
  -V, --verify / -NV, --noverify  Enable or disable verifying SSL cert for HTTP fetching.
  -r, --release TEXT              The FreeBSD release to fetch.
  -P, --plugin-name TEXT          Supply a plugin name for --plugins to fetch or use a auto completed filename for --plugin-name.
                                  Also accepts full path for a plugin file.
  --plugins                       List all available plugins for creation.
  -c, --count TEXT                Designate a number of plugin type jails to create.
  -d, --root-dir TEXT             Root directory containing all the RELEASEs.
  -U, --update / -NU, --noupdate  Decide whether or not to update the fetch to the latest patch level.
  -E, --eol / -NE, --noeol        Enable or disable EOL checking with upstream.
  -n, --name TEXT                 Specify which jail name to use. Leave empty for default selection based on --plugin-name.
  --accept / --noaccept           Accept the plugin's LICENSE agreement.
  -O, --official                  Lists only official plugins.
  --branch TEXT                   Select a different plugin branch (for development)
  -C, --thickconfig               Do not use inheritable configuration with plugins
  -S, --proxy TEXT                Provide proxy to use for creating jail
  --help                          Show this message and exit.

 

[tprelog]

I've never tried it myself, but the iocage fetch command has a --branch option.

I've used it... it works for a clean install but if you try running a Plugin UPDATE afterwards it will still pull from the default branch.

This would really help in testing new builds of an artifact.

What I used to do was install either gogs or gitea on my NAS and setup local plugin repositories for testing. Works just like pulling from github repos expect you need to use the console.

 

[Baenwort]

I've never tried it myself, but the iocage fetch command has a --branch option.

Code:

➜  ~ iocage fetch --help
Usage: iocage fetch [OPTIONS] [PROPS]...

  Fetch a version of FreeBSD for jail usage or a preconfigured plugin.

Options:
  -h, --http                      No-op flag for backwards compat
  -f, --file                      Use a local file directory for root-dir instead of HTTP
  -F, --files TEXT                Specify the files to fetch from the mirror.
  -s, --server TEXT               Server to fetch from.
  -g, --git_repository TEXT       Git repository to use to fetch plugin.
  -k, --keep_jail_on_failure      Keep jails on failure
  -u, --user TEXT                 The user to use.
  -p, --password TEXT             The password to use.
  -a, --auth TEXT                 Authentication method for HTTP fetching. Valid values: basic, digest
  -V, --verify / -NV, --noverify  Enable or disable verifying SSL cert for HTTP fetching.
  -r, --release TEXT              The FreeBSD release to fetch.
  -P, --plugin-name TEXT          Supply a plugin name for --plugins to fetch or use a auto completed filename for --plugin-name.
                                  Also accepts full path for a plugin file.
  --plugins                       List all available plugins for creation.
  -c, --count TEXT                Designate a number of plugin type jails to create.
  -d, --root-dir TEXT             Root directory containing all the RELEASEs.
  -U, --update / -NU, --noupdate  Decide whether or not to update the fetch to the latest patch level.
  -E, --eol / -NE, --noeol        Enable or disable EOL checking with upstream.
  -n, --name TEXT                 Specify which jail name to use. Leave empty for default selection based on --plugin-name.
  --accept / --noaccept           Accept the plugin's LICENSE agreement.
  -O, --official                  Lists only official plugins.
  --branch TEXT                   Select a different plugin branch (for development)
  -C, --thickconfig               Do not use inheritable configuration with plugins
  -S, --proxy TEXT                Provide proxy to use for creating jail
  --help                          Show this message and exit.

I'll give this a try but I suspect that it would just pull a branch of the .json and not a branch of the artefact repo called in the .json but perhaps if the branches have the same name it will pass the branch into the artefact call?

 

[tprelog]

It's going to be the artifact branch -- I don't think you can pull a specific json file

 

[Baenwort]

It's going to be the artifact branch -- I don't think you can pull a specific json file

I'll test it next time I'm free to poke at this. I was worried it would only pull a branch of the manifest and not a branch of the artefact. It would be great if it would pull the branch of both if they matched as it would make it easier to isolate my test builds from people who are using the main branch.

 

[Jurgen Segaert]

The official approach is that you would have a 13.1-RELEASE branch for your artifact repo with the production code, leaving you the master branch to develop and test.

TrueNAS 13 will attempt to pull the 13.1-RELEASE branch by default and only revert to master if that one doesn't exist.

 

[Baenwort]

It would be nice if all this was documented somewhere.

A follow up question for you @Jurgen Segaert can the manifest .json have a "branch" variable like it has a "release" variable? Would this pass to the iocage fetch that is used so that I could support keeping the Python2 original plug-in being installed until the PR to update ix-plugin manifest is merged and once that occurs it won't wreck things as then the new manifest would be pointed at the python3 branch until I was able to merge it into the 13.1-RELEASE branch then issue a PR to remove the "branch" variable from the manifest.json?

 

[Jurgen Segaert]

can the manifest .json have a "branch" variable like it has a "release" variable?

A while ago a PR was submitted to add such a variable, but it was never merged. The link is below; it links to the related issue that discusses the idea.

Optional plugin branch property by fulder · Pull Request #1250 · iocage/iocage

This PR adds a new optional branch plugin property to the manifest. Setting this property in the plugin manifest will clone/pull the plugin artifact from that branch rather than the TrueNAS FreeBSD...

github.com