[Vm-dev] How to restart an appveyor job?

[Nicolas Cellier]

Hi Fabio,
I've switched to curl for now and have a build in progress...
Anyway, cache or not cache, we are dependent on cygwin updates, and build
can start failing anytime (for example because a compiler version changed).

2018-04-02 18:13 GMT+02:00 Fabio Niephaus <lists at fniephaus.com>:

>
> On Mon, Apr 2, 2018 at 5:55 PM Ben Coman <btc at openinworld.com> wrote:
>
>> On 2 April 2018 at 20:32, Nicolas Cellier <nicolas.cellier.aka.nice@
>> gmail.com> wrote:
>>
>>>
>>> Hi all,
>>> I wanted to solve the gcc compiler bug for pharo.sista.spur.
>>>
>>> But of course, there were another failure due to fragile
>>> infrastructure...
>>> https://ci.appveyor.com/project/OpenSmalltalk/vm/build/1.0.1207/job/
>>> dd3lnytbwb5jjlqa
>>>
>>> Running Install scripts
>>> Start-FileDownload "http://cygwin.com/setup-x86.exe" -FileName
>>> "setup-x86.exe"
>>> Start-FileDownloadInternal : Error downloading remote file: One or more
>>> errors occurred.
>>> Inner Exception: Unable to connect to the remote server
>>> At C:\Program Files\AppVeyor\BuildAgent\Modules\build-worker-api\build-worker-api.psm1:242
>>> char:2
>>> + Start-FileDownloadInternal -Url $Url -FileName $FileName -Timeout ...
>>> + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>> + CategoryInfo : NotSpecified: (:) [Start-FileDownloadInternal],
>>> Exception
>>> + FullyQualifiedErrorId : System.Exception,Appveyor.
>>> BuildAgent.Api.Utils.StartFileDownloadInternalCmdlet
>>>
>>> We depend on volatile URL...
>>>
>>>
>> Seems quite susceptible to the ground unknowingly moving under our feet.
>> Actually I found it quite difficult (i.e. failed) to determine a hard
>> link to the version being installed.
>> To enhance reproduciblity, we should host our own versioned archive of
>> the required packages somewhere fairly permanent.
>>
>
> Instead of hosting our own Cygwin setup, maybe it's better to use the
> build cache [1]? We are already using that cache for third-party libs [2]
> and I also thought we'd cache Cygwin as well. @Nicolas: could you give this
> a go?
>
> Fabio
>
> [1] https://www.appveyor.com/docs/build-cache/
> [2] https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/
> 1614d9520f1ae901cdc4a5ba39d639a6ec5b1d84/.appveyor.yml#L113
>
>
>>
>> This seems pertinent...
>> 2.2.What about an automated Cygwin installation?
>> If you are deploying to multiple systems, the best way is to run through
>> a full installation once, saving the entire downloaded package tree. Then,
>> on target systems, run Cygwin Setup as a "Local Install" pointed at your
>> downloaded package tree. You could do this non-interactively with the
>> command line options -q -L -l x:\cygwin-local\, where your downloaded
>> package tree is in x:\cygwin-local\ (see the next FAQ for an explanation of
>> those options.)
>> (https://www.cygwin.com/faq.html)
>>
>> And "pmcyg" looks interesting...  "intended to support construction of
>> a self-contained CDROM or DVD that can be used to install or upgrade
>> Cygwin
>> on computers that do not have network access to a Cygwin mirror site."
>> (https://sourceforge.net/projects/pmcyg/files/pmcyg/pmcyg-2.2/)
>> That could be stored as a versioned archive which is added to the
>> appveyor build cache
>> so its only downloaded once,  saving per job build time and
>> ensuring if it succeeds at the first job, all other jobs *should* succeed.
>>
>> Options to host this versioned-cygwin-installer-archive (should be
>> somewhere fairly permanent):
>> * bintray
>> * github releases
>> * git large file storage
>> * files.opensmalltalk.org
>>
>> cheers -ben
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20180402/4dff1a51/attachment-0001.html>