git repositories for cygwin packaging - please test

[Jon TURNEY]

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
>
> Currently, many packages will fail to build correctly due to:

One problem I have noticed is that some packages have test suites (which
are getting run via 'cygport test' invoking src_test()) which:

- require lots of extra dependencies to run, or
- don't succeed on Cygwin, or
- take an inordinate amount of time to run (exceeding the resource limits)

So I'm wondering if .cygport files need:

- an annotation to indicate tests shouldn't be run by this system (in
RESTRICT? or somewhere new?)
- a separate TEST_REQUIRES to list packages which depended on for
running tests?

[cygwin-apps mailing list]

On 8/6/2020 4:20 PM, 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
>>
>> Currently, many packages will fail to build correctly due to:
>
> One problem I have noticed is that some packages have test suites (which are
> getting run via 'cygport test' invoking src_test()) which:
>
> - require lots of extra dependencies to run, or
> - don't succeed on Cygwin, or
> - take an inordinate amount of time to run (exceeding the resource limits)
>
> So I'm wondering if .cygport files need:
>
> - an annotation to indicate tests shouldn't be run by this system (in RESTRICT?
> or somewhere new?)
> - a separate TEST_REQUIRES to list packages which depended on for running tests?

I like both ideas.  For the first one (don't run 'cygport test'), I have a
slight preference for putting the annotation somewhere new, since it's pretty
different from the current uses of RESTRICT.  It doesn't affect what cygport
does, but rather it tells the automated system not to run a certain cygport command.

Ken

[Achim Gratz]

Jon Turney writes:
> One problem I have noticed is that some packages have test suites
> (which are getting run via 'cygport test' invoking src_test()) which:
>
> - require lots of extra dependencies to run, or

I currently subsume these in BUILD_REQUIRES as they are indeed required
for a (complete) build.  It'd be possible to split them out into a
separate variable indeed, but that is yet another level of
specificatrion that needs to be figured out if it should become useful.

> - don't succeed on Cygwin, or

Any such tests I usually patch out or mark expected fail whichever seems
easier.

> - take an inordinate amount of time to run (exceeding the resource limits)

That is a problem that comes with CI I think and we didn't really have
had to consider so far.  I have a few packages that I don't run tests on
by default because the test suite produces hangs or other unstable
behaviour, but that is dealt with in the src_test function itself.
If there are really resource hungry tests they usually need to be
enabled somewhere and one could skip those if the build runs on CIm (how
to find that out?).

> So I'm wondering if .cygport files need:
>
> - an annotation to indicate tests shouldn't be run by this system (in
> RESTRICT? or somewhere new?)

Not RESTRICT please, that does things related to packaging.

> - a separate TEST_REQUIRES to list packages which depended on for
> running tests?

That seems the most prudent name in this case.


Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Waldorf MIDI Implementation & additional documentation:
http://Synth.Stromeko.net/Downloads.html#WaldorfDocs

[cygwin-apps mailing list]

On 8/7/2020 3:42 PM, Achim Gratz wrote:

> Jon Turney writes:
>> One problem I have noticed is that some packages have test suites
>> (which are getting run via 'cygport test' invoking src_test()) which:
>>
>> - require lots of extra dependencies to run, or
>
> I currently subsume these in BUILD_REQUIRES as they are indeed required
> for a (complete) build.  It'd be possible to split them out into a
> separate variable indeed, but that is yet another level of
> specificatrion that needs to be figured out if it should become useful.
>
>> - don't succeed on Cygwin, or
>
> Any such tests I usually patch out or mark expected fail whichever seems
> easier.
>
>> - take an inordinate amount of time to run (exceeding the resource limits)
>
> That is a problem that comes with CI I think and we didn't really have
> had to consider so far.  I have a few packages that I don't run tests on
> by default because the test suite produces hangs or other unstable
> behaviour, but that is dealt with in the src_test function itself.
> If there are really resource hungry tests they usually need to be
> enabled somewhere and one could skip those if the build runs on CIm (how
> to find that out?).

Here's an example where Jon's suggestion would have been useful: While building
php recently, I noticed that the test suite took forever.  I would have been
happy to have a way to tell the CI to skip the tests and avoid exceeding the
resource limits.  But I wouldn't want to do that by modifying src_test, because
I would still want to run the tests locally.

Ken

[Achim Gratz]

Ken Brown via Cygwin-apps writes:

>>> - take an inordinate amount of time to run (exceeding the resource limits)
>>
>> That is a problem that comes with CI I think and we didn't really have
>> had to consider so far.  I have a few packages that I don't run tests on
>> by default because the test suite produces hangs or other unstable
>> behaviour, but that is dealt with in the src_test function itself.
>> If there are really resource hungry tests they usually need to be
>> enabled somewhere and one could skip those if the build runs on CI (how
>> to find that out?).
>
> Here's an example where Jon's suggestion would have been useful: While
> building php recently, I noticed that the test suite took forever.  I
> would have been happy to have a way to tell the CI to skip the tests
> and avoid exceeding the resource limits.  But I wouldn't want to do
> that by modifying src_test, because I would still want to run the
> tests locally.

I think I didn't express myself clearly enough.  If you look in the
perl-IO-Tty cygport file you'll find this:

src_test() {
    cd ${B}
    [ "no" != "${CYGPORT_RUN_UNSTABLE_TESTS-no}" ] &&
     cygtest || echo "Unstable test, set CYGPORT_RUN_UNSTABLE_TESTS to run."
}

This is clearly an exceptional deficiency (even if presumably caused by
some border case in Cygwin) that needs to be handled in the package and
not a general thing that should be in cygport.

But that's not to say that something like CYGPORT_RUN_EXPENSIVE_TESTS
could not exist and arguably it should even be directly provided by
cygport itself if it was.  Now, "expensive" has multiple dimensions, so
I'd expect that variable to have a list of values to indicate which of
these is considered relevant (like time, memory, network).  There'd need
to be a matching set of values / limits provided by the local or CI
configuration to enable / disable tests as appropriate.

CPU wise the CI seems to have a pretty beefy configuration, I've not run
into memory problems yet (but didn't check that specifically).  So at
the moment the relevant limits would be total runtime and maybe network
activity (I don't think I have a package that exercises that).  But then
again, this could change with each run and certainly will change over
time, so hard-coding these limits doesn't seem like a good idea.


Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf rackAttack:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

[Jon TURNEY]

On 07/08/2020 23:05, Ken Brown via Cygwin-apps wrote:

> On 8/7/2020 3:42 PM, Achim Gratz wrote:
>> Jon Turney writes:
>>> One problem I have noticed is that some packages have test suites
>>> (which are getting run via 'cygport test' invoking src_test()) which:
>>>
>>> - require lots of extra dependencies to run, or
>>
>> I currently subsume these in BUILD_REQUIRES as they are indeed required
>> for a (complete) build.  It'd be possible to split them out into a
>> separate variable indeed, but that is yet another level of
>> specificatrion that needs to be figured out if it should become useful.

Yeah, the only saving is that we don't need to spend the time to install
those packages if we aren't going to run the tests.

>>> - don't succeed on Cygwin, or
>>
>> Any such tests I usually patch out or mark expected fail whichever seems
>> easier.
>>
>>> - take an inordinate amount of time to run (exceeding the resource
>>> limits)
>>
>> That is a problem that comes with CI I think and we didn't really have
>> had to consider so far.  I have a few packages that I don't run tests on
>> by default because the test suite produces hangs or other unstable
>> behaviour, but that is dealt with in the src_test function itself.
>> If there are really resource hungry tests they usually need to be
>> enabled somewhere and one could skip those if the build runs on CIm (how
>> to find that out?).
>
> Here's an example where Jon's suggestion would have been useful: While
> building php recently, I noticed that the test suite took forever.  I
> would have been happy to have a way to tell the CI to skip the tests and
> avoid exceeding the resource limits.  But I wouldn't want to do that by
> modifying src_test, because I would still want to run the tests locally.

It should now be possible to add to the .cygport a line like:

SCALLYWAG="notest"

which instructs it not to run the src_test() phase.

[Jon TURNEY]

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
>
> Currently, many packages will fail to build correctly due to:

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.

Currently, these packages are built using 'cygport all-test', and so
will always be marked test:

One possible issue is that a git commit doesn't have to change VERSION
or RELEASE, so this can build packages which are then immediately
rejected by calm, as that PVR already exists.

I'm not sure if that's a real problem, or what the workflow should look
like in regards to that.

[cygwin-apps mailing list]

On 8/23/2020 5:01 PM, 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
>>
>> Currently, many packages will fail to build correctly due to:
>
> 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.

I'd be willing to give it a try the next time I have something to upload.  I'm
actually almost ready for a test release of doxygen.  Unfortunately, the 32-bit
scallywag build of doxygen consistently fails with an ld crash, even though I
can build it locally.  So I can't use it for this test.

How does the opt-in process work?  Is it per package?  Is it easy to opt-out
again temporarily?

> Currently, these packages are built using 'cygport all-test', and so will always
> be marked test:
>
> One possible issue is that a git commit doesn't have to change VERSION or
> RELEASE, so this can build packages which are then immediately rejected by calm,
> as that PVR already exists.

Does calm delete them after rejecting them or does the maintainer have to do that?

> I'm not sure if that's a real problem, or what the workflow should look like in
> regards to that.

I don't see it as a real problem, as long as all it means is that I get an email
from calm.  But if I also have to manually delete the packages from my upload
area, that could be annoying.

Ken

[Jon TURNEY]

On 26/08/2020 23:00, Ken Brown via Cygwin-apps wrote:

> On 8/23/2020 5:01 PM, Jon Turney wrote:
>>
>> 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.
>
> I'd be willing to give it a try the next time I have something to
> upload.  I'm actually almost ready for a test release of doxygen.  
> Unfortunately, the 32-bit scallywag build of doxygen consistently fails
> with an ld crash, even though I can build it locally.  So I can't use it
> for this test.
>
> How does the opt-in process work?  Is it per package?  Is it easy to
> opt-out again temporarily?

We can arrange the details however you like.  A specific package might
be a good idea for a first try.

Only pushes to master are considered. You can opt-out by adding
'SCALLYWAG=nodeploy' to the cygport.

>> Currently, these packages are built using 'cygport all-test', and so
>> will always be marked test:
>>
>> One possible issue is that a git commit doesn't have to change VERSION
>> or RELEASE, so this can build packages which are then immediately
>> rejected by calm, as that PVR already exists.
>
> Does calm delete them after rejecting them or does the maintainer have
> to do that?

I've actually recently made a change to calm so that packages rejected
as duplicates of existing PVR are discarded rather than retained, as
this was just an inconvenience with no benefit.

>> I'm not sure if that's a real problem, or what the workflow should
>> look like in regards to that.
>
> I don't see it as a real problem, as long as all it means is that I get
> an email from calm.  But if I also have to manually delete the packages
> from my upload area, that could be annoying.

[cygwin-apps mailing list]

On 8/30/2020 11:00 AM, Jon Turney wrote:

> On 26/08/2020 23:00, Ken Brown via Cygwin-apps wrote:
>> On 8/23/2020 5:01 PM, Jon Turney wrote:
>>>
>>> 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.
>>
>> I'd be willing to give it a try the next time I have something to upload.  I'm
>> actually almost ready for a test release of doxygen. Unfortunately, the 32-bit
>> scallywag build of doxygen consistently fails with an ld crash, even though I
>> can build it locally.  So I can't use it for this test.
>>
>> How does the opt-in process work?  Is it per package?  Is it easy to opt-out
>> again temporarily?
>
> We can arrange the details however you like.  A specific package might be a good
> idea for a first try.

OK, I've got a test release of ghostscript ready to go.  I've already tested it
on the playground branch, so I know it builds.  If I put 'SCALLYWAG=deploy' in
the cygport and push to master, will that do the job?

> Only pushes to master are considered. You can opt-out by adding
> 'SCALLYWAG=nodeploy' to the cygport.

That sounds fine.

>>> Currently, these packages are built using 'cygport all-test', and so will
>>> always be marked test:
>>>
>>> One possible issue is that a git commit doesn't have to change VERSION or
>>> RELEASE, so this can build packages which are then immediately rejected by
>>> calm, as that PVR already exists.
>>
>> Does calm delete them after rejecting them or does the maintainer have to do
>> that?
>
> I've actually recently made a change to calm so that packages rejected as
> duplicates of existing PVR are discarded rather than retained, as this was just
> an inconvenience with no benefit.

Good.

Ken

[Jon TURNEY]

On 30/08/2020 16:22, Ken Brown wrote:

> On 8/30/2020 11:00 AM, Jon Turney wrote:
>> On 26/08/2020 23:00, Ken Brown via Cygwin-apps wrote:
>>> On 8/23/2020 5:01 PM, Jon Turney wrote:
>>>>
>>>> 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.
>>>
>>> I'd be willing to give it a try the next time I have something to
>>> upload.  I'm actually almost ready for a test release of doxygen.
>>> Unfortunately, the 32-bit scallywag build of doxygen consistently
>>> fails with an ld crash, even though I can build it locally.  So I
>>> can't use it for this test.
>>>
>>> How does the opt-in process work?  Is it per package?  Is it easy to
>>> opt-out again temporarily?
>>
>> We can arrange the details however you like.  A specific package might
>> be a good idea for a first try.
>
> OK, I've got a test release of ghostscript ready to go.  I've already
> tested it on the playground branch, so I know it builds.  If I put
> 'SCALLYWAG=deploy' in the cygport and push to master, will that do the job?

Sure, I have made things work like that.

Go ahead when you are ready.

>> Only pushes to master are considered. You can opt-out by adding
>> 'SCALLYWAG=nodeploy' to the cygport.
>
> That sounds fine.

[Achim Gratz]

Jon Turney writes:
> Only pushes to master are considered. You can opt-out by adding
> 'SCALLYWAG=nodeploy' to the cygport.

If additionally we'd not want the package to get tested, would we do

SCALLYWAG="notest nodeploy"

or

SCALLYWAG="notest"
SCALLYWAG+=" nodeploy"

is supposed to work, then?


Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Samples for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra

[cygwin-apps mailing list]

On 8/30/2020 11:46 AM, Jon Turney wrote:

> On 30/08/2020 16:22, Ken Brown wrote:
>> On 8/30/2020 11:00 AM, Jon Turney wrote:
>>> On 26/08/2020 23:00, Ken Brown via Cygwin-apps wrote:
>>>> On 8/23/2020 5:01 PM, Jon Turney wrote:
>>>>>
>>>>> 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.
>>>>
>>>> I'd be willing to give it a try the next time I have something to upload.  
>>>> I'm actually almost ready for a test release of doxygen. Unfortunately, the
>>>> 32-bit scallywag build of doxygen consistently fails with an ld crash, even
>>>> though I can build it locally.  So I can't use it for this test.
>>>>
>>>> How does the opt-in process work?  Is it per package?  Is it easy to opt-out
>>>> again temporarily?
>>>
>>> We can arrange the details however you like.  A specific package might be a
>>> good idea for a first try.
>>
>> OK, I've got a test release of ghostscript ready to go.  I've already tested
>> it on the playground branch, so I know it builds.  If I put 'SCALLYWAG=deploy'
>> in the cygport and push to master, will that do the job?
>
> Sure, I have made things work like that.
>
> Go ahead when you are ready.

It worked.  It took me two tries because the first time I added
'SCALLYWAG=deploy' I forgot to commit it before pushing.

[Jon TURNEY]

On 30/08/2020 18:25, Ken Brown via Cygwin-apps wrote:

> On 8/30/2020 11:46 AM, Jon Turney wrote:
>> On 30/08/2020 16:22, Ken Brown wrote:
>>>
>>> OK, I've got a test release of ghostscript ready to go.  I've already
>>> tested it on the playground branch, so I know it builds.  If I put
>>> 'SCALLYWAG=deploy' in the cygport and push to master, will that do
>>> the job?
>>
>> Sure, I have made things work like that.
>>
>> Go ahead when you are ready.
>
> It worked.  It took me two tries because the first time I added
> 'SCALLYWAG=deploy' I forgot to commit it before pushing.

That's a pleasant surprise :)

It should work in a similar way (for you) for any other packages.

[Jon TURNEY]

On 30/08/2020 17:44, ASSI wrote:

> Jon Turney writes:
>> Only pushes to master are considered. You can opt-out by adding
>> 'SCALLYWAG=nodeploy' to the cygport.
>
> If additionally we'd not want the package to get tested, would we do
>
> SCALLYWAG="notest nodeploy"
>
> or
>
> SCALLYWAG="notest"
> SCALLYWAG+=" nodeploy"
>
> is supposed to work, then?
>

Yes.

But "nodeploy" is the default for everyone apart from Ken Brown and me,
at the moment.

[Achim Gratz]

ASSI writes:
> SCALLYWAG="notest"

It seems that if I write something like

 SCALLYWAG="notest" # a comment

then the line actually gets ignored due to a somewhat restrictive regex:

match = re.search(r'^\s*SCALLYWAG=\s*"?(.*?)"?$', content, re.MULTILINE)

Something like this might work better:

match = re.search(r'^\s*SCALLYWAG=\s*"?(.*?)"?(\s*#.*)?$', content, re.MULTILINE)

(I hope :-).  Otherwise you'd first need to chop off any comments at the
end and then shove the result into the original regex.

It seems like there is a lot of ad-hoc code in that file that does
things slightly differently for various settings, so that seems like it
should get re-factored into something more general that is used
uniformly across all the things you want to extract from the cygport
file.


Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf rackAttack V1.04R1:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

[Jon TURNEY]

On 04/10/2020 11:26, Achim Gratz wrote:

> ASSI writes:
>> SCALLYWAG="notest"
>
> It seems that if I write something like
>
>   SCALLYWAG="notest" # a comment
>
> then the line actually gets ignored due to a somewhat restrictive regex:
>
> match = re.search(r'^\s*SCALLYWAG=\s*"?(.*?)"?$', content, re.MULTILINE)
>
> Something like this might work better:
>
> match = re.search(r'^\s*SCALLYWAG=\s*"?(.*?)"?(\s*#.*)?$', content, re.MULTILINE)
>
> (I hope :-).  Otherwise you'd first need to chop off any comments at the
> end and then shove the result into the original regex.
>
> It seems like there is a lot of ad-hoc code in that file that does
> things slightly differently for various settings, so that seems like it
> should get re-factored into something more general that is used
> uniformly across all the things you want to extract from the cygport
> file.

As noted elsewhere, trying to parse variables out of the .cygport like
this isn't a good approach, and really I want to add something which
gets cygport to execute the file and then output the variables of interest.

But I've tweaked things a bit so comments should get discarded before we
start looking at the file contents, which hopefully helps this a bit.

[Jon TURNEY]

On 30/08/2020 16:46, Jon Turney wrote:

> On 30/08/2020 16:22, Ken Brown wrote:
>> On 8/30/2020 11:00 AM, Jon Turney wrote:
>>> On 26/08/2020 23:00, Ken Brown via Cygwin-apps wrote:
>>>> On 8/23/2020 5:01 PM, Jon Turney wrote:
>>>>>
>>>>> 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.
>>>>
>>>> I'd be willing to give it a try the next time I have something to
>>>> upload.  I'm actually almost ready for a test release of doxygen.
>>>> Unfortunately, the 32-bit scallywag build of doxygen consistently
>>>> fails with an ld crash, even though I can build it locally.  So I
>>>> can't use it for this test.
>>>>
>>>> How does the opt-in process work?  Is it per package?  Is it easy to
>>>> opt-out again temporarily?
>>>
>>> We can arrange the details however you like.  A specific package
>>> might be a good idea for a first try.
>>
>> OK, I've got a test release of ghostscript ready to go.  I've already
>> tested it on the playground branch, so I know it builds.  If I put
>> 'SCALLYWAG=deploy' in the cygport and push to master, will that do the
>> job?
>
> Sure, I have made things work like that.
>
> Go ahead when you are ready.

This is now enabled for all maintainers.

To summarize, the following tokens are recognized in the SCALLYWAG
variable set in the .cygport file:

nobuild: Disables building packages.

notest: Disables running 'cygport test'

deploy: For the master branch, after a successful build, the built
packages are handed-off to calm, the package uploader.

Note that currently, these packages are built using 'cygport
all-test', and so will always be marked as test.c

[Brian Inglis]

On 2020-05-27 16: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

> To allow experimentation without messing up the version history unnecessarily:
>
> - All package repositories allow the maintainer(s) to create, push, rewind and
> delete a branch named 'playground'.
>
> - An additional package repository called 'playground' exists, that all
> maintainers can do anything to.

Could anyone please check and advise if the attached .git/config will allow me
to push to the playground repo and later branch for testing, or demo the
appropriate .git/config entries or git config commands to do so properly?

Is there any way to move tags to a later commit once pushed?
I have one in wget that can't be deleted or forced because of the hook fallthru.

Finally are there other CI jobs.cgi?params=... other than id, e.g.
jobs.cgi?by=Brian+Inglis?

--
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in binary units and prefixes, physical quantities in SI.]

[Jon TURNEY]

On 16/11/2020 21:54, Brian Inglis wrote:

> On 2020-05-27 16: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
>
>> To allow experimentation without messing up the version history
>> unnecessarily:
>>
>> - All package repositories allow the maintainer(s) to create, push,
>> rewind and delete a branch named 'playground'.
>>
>> - An additional package repository called 'playground' exists, that
>> all maintainers can do anything to.
>
> Could anyone please check and advise if the attached .git/config will
> allow me to push to the playground repo and later branch for testing, or
> demo the appropriate .git/config entries or git config commands to do so
> properly?

To push to the playground repo, I generally just use 'git push
ssh://[hidden email]/git/cygwin-packages/playground.git -f'.

The URLs in that config don't look quite right, since they seem to have
hostname of just 'cygwin'?

> Is there any way to move tags to a later commit once pushed?
> I have one in wget that can't be deleted or forced because of the hook
> fallthru.

tags don't have any particular significance, at the moment.

I removed the wget '1.20.3-2' tag for you.

> Finally are there other CI jobs.cgi?params=... other than id, e.g.
> jobs.cgi?by=Brian+Inglis?

Not at this time.  I agree it would be nice if you could filter by the
various columns.

The jobs.cgi script script is tiny (see [1]), if you want to make
improvements.

[1] https://cygwin.com/git/?p=cygwin-apps/scallywag.git;a=blob;f=jobs.cgi