Get that Linux feeling - on Windows
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).
Packages may fail to build correctly due to:
- missing or insufficient
- missing prerequisites implied by an
- 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 serviceThe behaviour of the build service can be controlled, with the tokens described below:
- for an individual push
git push --push-option="token [token...]"
- for a package
by setting the value of the
SCALLYWAGvariable in the
The default value may be specified in a
!scallywagfile 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.
Build service tokens
Enables building packages.
Disables building packages.
Label the packages as
For the master branch, after a successful build, the built packages are handed-off to the package uploader.
Take no action after a successful build.