0.13 (2022-08-10)¶

Allow project configuration path overrides¶

When loading a project’s configuration file, releng-tool will look for a configuration file found in the <root>/releng path. If a user wishes to load releng-tool with an alternative configuration (either for testing, using multiple configurations, etc.), users can now specify the path of a configuration file to load using the --config argument. For example:

releng-tool --config my-second-config

Support for make and SCons package types¶

Introduction of the make and scons package types. These new package types allow a developer to easily invoke Make and SCons targets at various stages, without needing invoke these tools inside a scripts package.

Support for Python setup types¶

Python packages can now tailor their build and installation stages by configuration setup types. Packages would originally be processed as if they were distutils-managed packages. releng-tool now support additional setup types:

For example, if a Python package wishes to use Setuptools, the following can be used:

LIBFOO_TYPE = 'python'
LIBFOO_PYTHON_SETUP_TYPE = 'setuptools'

For PEP 517 build systems, the installer module will be used to install packages to host, staging and target areas.

Support development modes¶

Specific development modes are now supported for a releng-tool run. Developers can switch between a development version of a package over a stable version by first enabling development mode:

releng-tool --development

For example, with development mode enabled, a LIBFOO package would instead fetch sources from the main branch with the following package configuration:

LIBFOO_DEVMODE_REVISION = 'main'
LIBFOO_REVISION = 'v3.0'

Developers may wish to have more than one alternative mode to target for, as well as tweaking sites depending on the mode. A user can now invoke the development argument with a mode value, which hints to the name of the mode to build with. For example, if a user invoked releng-tool with the following:

releng-tool --development test

Subsequent runs will now be running under the test mode. If a package is configured with test-specific mode, it can change what revision a package will use as well as other possible tweaks. For example, with the following package definition:

LIBFOO_SITE = {
    DEFAULT_SITE: 'https://pkgs.example.com/releases/libfoo-${LIBFOO_VERSION}.tar.gz',
    'test': 'https://git.example.com/libfoo.git',
}

LIBFOO_REVISION = {
    'test': 'main',
}

The LIBFOO package would normally fetch an archive folder based off the configured version value. When operating in a test development mode, sources for LIBFOO will now be fetched from the provided Git repository using the main branch.

Support path overrides for local-sources mode¶

Users have had the ability to enable local-sources mode to load sources of internal-marked packages from a local file system. This was achieved using the --local-sources argument to enable this mode. The idea is allow users developing on internal packages to clone packages in their development environment manually, where releng-tool can build against and users can use their own Git tools/capabilities to manage their sources.

Local-sources mode was limited on its usage. When enabled, all internal packages were looked for in a parent path of a configured root directory, without having any option to change the path or ignore for select packages. With this most recent version, these options are now available.

The default of --local-sources (or just -L) will configure an environment to look for packages in the parent folder of the root directory. For example, if a project has a liba package, sources for the package will be found under <root-dir>/../liba. If a user provides a path to the --local-sources argument, packages will now be looked for inside the provided folder. For example:

releng-tool --local-sources ~/workdir

Continuing with the example of liba, the sources for this packages will now be looked for inside ~/workdir/liba.

There can be cases where a developer may need to tweak the path of a specific package. If a user specifies the package name prefixed to a path inside the command line argument, a user can override where the specific package sources are found. For example:

releng-tool -L ~/anotherdir -L libb@/mnt/share/libb

The above shows an example where sources for all internal packages will be looked for inside ~/anotherdir, with the exception of libb which will look for its sources directly in the /mnt/share/libb path.

Users also have the ability to ignore local-sources for a specific package (i.e. “fetch all packages locally but these ones”). Consider the following example:

releng-tool -L ~/morework -L libc@

The above shows an example where sources for all internal packages will be looked for inside ~/morework, with the exception of libc which will checkout sources normally as if local-sources mode was not enabled.

Reminder that users can disable local-sources mode by performing a distclean action, or manually removing the .releng-flag-local-sources file.

New copy-into script function¶

The releng_copy_into helper function has been added to allow releng-tool script to explicitly copy a source into a target directory. This can be helpful for users who wish to avoid scenarios using releng_copy to ensure the destination directory exists or avoiding the need to add a trailing file separator at the end of the destination target. An example of this new call is as follows:

releng_copy_into('my-file', 'my-directory')

Support certificates override for bzr¶

When a package is configured to fetch bzr sources, select environments may have issues attempting to download from Launchpad (or other hosting) due to legacy certificates.

See `bzr help ssl.ca_certs` for how to specify trusted CAcertificates.
Pass -Ossl.cert_reqs=none to disable certificate verification entirely.

If a user’s environment has certifi installed, a user can invoke releng-tool with the quirk releng.bzr.certifi enabled to use certifi’s certificates instead. For example:

releng-tool --quirk releng.bzr.certifi