The Tox Project runs a Jenkins continuous integration server as a convenience to client developers who may not have the time or money to set up their own. Any Tox-related project is free to use our Jenkins server for their project without charge. All we ask is that you follow the guidelines on this page.

If you'd like to use our Jenkins server for your project's continuous integration, please send an email to the server administrator.

1. Limit the number of builds you archive, since disk space is limited.
   • 5 to 10 archived builds for jobs with a small disk footprint, and 1 or 2 for big footprints is a common setting.
2. Tag your builds to the build machine of the appropriate architecture.
   • Although the x86 and x86-64 build machines have both x86 and x86-64 Windows cross-compilers installed, cross-compile x86 on the x86 build slave and x86-64 on the x86-64 build slave.
   • The only exception to these rules are android clients, which are built on the x86-64 machine, no matter the target architecture.
3. Please follow the naming guidelines when naming jobs (This is enforced via regex).
4. Archive job artifacts in the .tar.xz format when building for Linux and .zip when building for Windows.
   • Use .tar.xz for all *_src jobs, regardless of platform, since they will be used on our Linux build machines.
5. Give build artifacts the same name as the job, plus .tar.xz or .zip.
   • You can use the $(JOB_NAME) environment variable instead of copy-pasting the job name directly.
6. All of the jobs you use artifacts from should be upstream¹⁾ of your job.
7. Split source-code-pulling, building and packaging into separate jobs that depend on each other via an upstream/downstream relationship.
   • Your source code should be pulled only by *_src jobs, which will trigger _*build_* jobs, which will trigger *_pkg_* jobs.
   • This is done to save bandwidth and eliminate redundancy.
8. Don't automatically schedule a build based on a time interval (the crontab option).
   • An alternative is to use something like GitHub web hooks, so that your job is scheduled for building only when you push to your repository (when the source code actually changes).
9. Don't use rm -rf * to clean up a workspace before a build starts; use the “Delete workspace before build starts” configuration option.
10. If you choose to use the IRC notification post-build hook to output messages to the #tox-dev channel, please try to keep the output minimal; there are lots of projects using the same notifications, and we'd like to keep our channel from becoming a wall of IRC bot spam.
11. If you use libtools, you will need to update the .la and .pc package configs to point to wherever you unpacked the source libraries in your workspace.

1. The Jenkins slaves use apparmour to prevent builds from writing to anywhere outside of their workspaces (some exceptions apply), if you need an exception, please contact us with justification.
2. Do not sign packages or store private keys for any length of time.
3. Job configurations are public.

• If you need a package installed please contact the administrators via IRC or through email.

• Guidelines for Linux packaging can be found here.