Table of Contents
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