How to avoid tying up scallywag
Ken Brown
kbrown@cornell.edu
Mon Mar 20 13:14:11 GMT 2023
On 3/20/2023 7:22 AM, Jon Turney wrote:
> On 19/03/2023 23:04, Ken Brown via Cygwin-apps wrote:
>> Jon,
>>
>> I'll be ready to go with TeX Live 2023 in a couple days. That
>> involves about 60 packages. If I push them all at once, I'm afraid
>> that would tie up scallywag and make it unusable by others. I was
>> thinking of pushing them in batches of 5, with a couple hours in
>> between batches. But I don't know how many jobs scallywag can do at
>> once. What do you think?
>
> As far as I can tell, the documented limits for the GitHub free service
> currently used are currently:
>
> * 20 concurrent jobs
> * runs which are queued for more than 45 minutes without starting are
> discarded.
So I should even be able to do 10 or 15 at once without clogging the
system. Maybe I'll start with one batch of 15 and see what happens.
> The implementation of how the build back-end is used in scallywag is
> moderately modularized, so if these restrictions become irksome, and we
> ever have access to a better compute service, that could be used instead.
>
>
> Note that if you are just updating the repository, without using
> scallywag to deploy, then pushing with --push-option=nobuild is more
> slightly more efficient that SCALLYWAG="nobuild" in the cygport, as it
> can short-cut things, since it doesn't need to start a job to evaluate
> the tokens to determine if nobuild is set.
Good to know, but in the present case I'm planning to deploy.
Ken
More information about the Cygwin-apps
mailing list