On 2/18/2023 11:21 AM, Jon Turney via Cygwin-apps wrote:
On 05/07/2022 14:12, Jon Turney wrote:
On 22/06/2021 20:52, Jon Turney wrote:
On 09/05/2021 15:39, Jon Turney wrote:
On 23/08/2020 22:01, Jon Turney wrote:
On 27/05/2020 23:27, Jon Turney wrote:
On 04/08/2019 21:08, Jon Turney wrote:
To remedy this lack, using the same ssh key you use for sftp
package upload, package maintainers can now also push to git
repositories, like so:
Package maintainers may have noticed that the output from pushing
to these git repositories now includes a line like:
"remote: scallywag: build nnn queued"
This is a *prototype* of a system to automatically build the
packages, where the results appear (some time later) at [1] (URL
subject to change)
[1] https://cygwin.com/cgi-bin2/jobs.cgi
I now have built an (opt-in) system which fetches the packages
built by this into your upload area and triggers calm to process
them, which I'm looking for a volunteer to test.
Since that seems to be working about as well as can be expected,
I've bodged together something so maintainers can now opt themselves
in (and out) of this, by uploading (or removing) a file called
'!scallywag' containing 'deploy' in the root of their upload area.
I've updated the brief documentation at [1] to mention this.
[1] https://cygwin.com/packaging/build.html
I've updated that page to document the fact that the behaviour for an
individual push can now be controlled with 'git push
--push-option=<token>'.
Currently, these packages are built using 'cygport all-test', and
so will always be marked test:
Since my concerns about this producing horribly broken packages seem
to be moot, I've changed the default so this now produces stable
packages (i.e. uses 'cygport all' rather than 'cygport all-test'').
You can request the previous behaviour of labelling as test using the
token 'label'.
You can now interact with your build jobs in some ways which require
authentication using 'ssh cyg...@cygwin.com jobs'.
Thanks!
Currently, available sub-commands are:
cancel (request termination of an unwanted build job)
deploy (get a job to deploy (if it's suitable: i.e. successfully built,
from master, etc.) (e.g. if you forgot to set the deploy option before
hand)
I assume we would specify the job id after the cancel or deploy command?
rebuild (rebuild a job if it failed due to some transient condition, or
optionally with different token options)
For the second case, would we specify the new tokens on the command
line? After the job id?
Ken
