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

Fabio Niephaus lists at fniephaus.com
Mon Apr 2 16:34:45 UTC 2018


On Mon, Apr 2, 2018 at 6:23 PM Nicolas Cellier <
nicolas.cellier.aka.nice at gmail.com> wrote:

>
> Hi Fabio,
> I've switched to curl for now and have a build in progress...
>

curl makes sense!


> Anyway, cache or not cache, we are dependent on cygwin updates, and build
> can start failing anytime (for example because a compiler version changed).
>

That's right. Another idea for hosting our custom Cygwin: another Git
repository, for example OpenSmalltalk/build-cygwin. This way, we could
track changes as well.


>
> 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 at 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/be382431/attachment-0001.html>


More information about the Vm-dev mailing list