Package build service

After pushing to a package git repository, an automatic build of the package is queued:

  remote: scallywag: build nnnn queued
  remote: scallywag: https://cygwin.com/cgi-bin2/jobs.cgi?id=nnnn

The results will appear (some time later) at https://cygwin.com/cgi-bin2/jobs.cgi (URL subject to change).

Caveats

Packages may fail to build correctly due to:

• missing or insufficient BUILD_REQUIRES
• missing prerequisites implied by an inherit
• other bugs in this service
• resource limits imposed by the free service used to perform the actual builds

(Note that a successful build doesn't always mean that you have reproduced your local build: You'll also need to check the configuration step output and/or dependencies of the produced packages are the same. Consider explicitly enabling the functionality you are expecting in the options to the configure script, if it supports that (e.g. CYGCONF_ARGS, etc.), to avoid it potentially silently turning off in future, if it's requirements change.)

Controlling the build service

The behaviour of the build service can be controlled, with the tokens described below:

• for an individual push
  

  with git push --push-option="token [token...]"

• for a package
  

  by setting the value of the SCALLYWAG variable in the .cygport file

• per-maintainer
  

  The default value may be specified in a !scallywag file in the root of a maintainer's upload directory tree.

  Additionally, if that file contains disable, this service is completely disabled for all of that maintainer's pushes.

Tokens from all the sources above are collected together, along with the default set of build test. The presence of a negated token takes priority over the presence of an unnegated token.

Interacting with build service jobs

Interactions with build service jobs which require authentication can be done with ssh cygwin@cygwin.com jobs. Available sub-commands are:

• cancel
  request termination of a build job.
• deploy
  hand-off built packages from a job to the package uploader (if it's suitable: i.e. successfully built, from master, etc.).
• rerun
  rerun a job (e.g. if it failed due to some transient condition, or optionally with different tokens).

Build service tokens

• build
  Enables building packages.
• nobuild
  Disables building packages.
• label
  Label the packages as test: using cygport package-test.
• test
  Enables running cygport test.
• notest
  Disables running cygport test.
• deploy
  For the master branch, after a successful build, the built packages are handed-off to the package uploader.
  
• nodeploy
  Take no action after a successful build.