git repositories for cygwin packaging - please test

Ken Brown
Sat Feb 18 17:43:00 GMT 2023

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]
>>>>> 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]
>>> 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 jobs'.


> 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?


More information about the Cygwin-apps mailing list