About Packaging

If you decide to use Jenkins for packaging (and optionally shipping those packages to our official repository), please follow the guidelines on this page.

Package Info File

Owners of _build_ jobs should add a PACKAGE_INFO file to their artifacts containing the following bash variables:

  • PROGRAM_NAME
  • VERSION
  • GIT_REF
  • ARCH

This file will be useful for anyone packaging your project. It may be sourced into a shell script, so try to keep the format sane.

Packaging Guidelines

  • You should only bump the package version when actual code changes have been made - as a packager, set the version via some combination of VERSION-GITREF, PACKAGE_VERS=“$VERSION-$(echo $GIT_REF | cut -c 1-7)” is common
  • Other options are available - although we ask that you avoid relying on the jenkins BUILDJOB number, as it can lead to pointless version bumps if you need to rebuild the package job for testing or other administrative tasks

Shipping Packages

If you'd like us to serve your packages on the official Tox Project package repository, send an email to infrastructure@tox.chat with the name of your Jenkins job(s), requesting that your package(s) be added to the package repository. Once your job name is on our whitelist, your packages will be pulled automatically once every day. This is to ensure that devs can't clobber each other's packages (either intentionally or inadvertently).

The table below shows what channel and dist your build will end up in.

${JOB_NAME} matches _nightly_ anything else
_debug_ nightly-debug stable-debug
anything else nightly-release stable-release

If the above doesn't meet your requirements, ask us to improve it (infrastructure@tox.chat).

Distro Specific Help and Resources

You can use the following skeleton script to get started with Debian Packages

Print/export