Thread: Cirrus CI (Windows help wanted)

Hi,

My new favourite CI is Cirrus CI, because it has 4 operating systems,
generous enough quotas to handle 250+ branches in a single account,
and public build/test log URLs.  I flipped cfbot.cputube.org (mostly)
over to that and it seems to work well so far -- fingers crossed.
I've also been using it for my own development branches that involve
some systems hacking-heavy work that uses different kernel interfaces
on all 4 of those OSes.

There's one thing I'm stuck on, though: Windows.  If anyone wants to
help figure out how to get PostgreSQL to build on Cirrus's Windows,
I'd be very interested.  To play with this stuff, you need a public
Github repo, and you need to add Cirrus CI from "Marketplace" (it's
free for public/open source), and then you add a .cirrus.yml file such
as https://github.com/macdice/cfbot/blob/master/cirrus/.cirrus.yml to
the top level of a PostgreSQL branch.  When you push, you should see
build results on the Github web UI.

For a similar example that works on Windows on another CI, see
https://github.com/macdice/cfbot/blob/master/appveyor/appveyor.yml
(note that it also references a couple of other files; it'd be nice to
be able to do that stuff without the need for separate files, possibly
by using Power Shell).  That's what cfbot is using for Windows for
now, which works really well, but it'd be nice to have more
options/choices.  For another example of Windows builds working on
another CI, see the Github Actions patch I posted earlier when I was
considering that for cfbot[1].  I think what's different is that those
other CIs have images with MSVC on them, but Cirrus wants you to
figure out how to install the right toolchain yourself (and then, as a
next step after it's actually working, it also provides a way to
define what you want in a way that captures the resulting image using
Docker voodoo, so that you get fast startup times).  Or something.

[1]
https://www.postgresql.org/message-id/flat/CA%2BhUKG%2By_SHVQcU3CPokmJxuHp1niebCjq4XzZizf8SR9ZdQRQ%40mail.gmail.com

I happened to get tired by waiting for active perl building repeatedly..

At Tue, 5 Jan 2021 16:58:36 +1300, Thomas Munro <thomas.munro@gmail.com> wrote in 
> Hi,
> 
> My new favourite CI is Cirrus CI, because it has 4 operating systems,
> generous enough quotas to handle 250+ branches in a single account,
> and public build/test log URLs.  I flipped cfbot.cputube.org (mostly)
> over to that and it seems to work well so far -- fingers crossed.
> I've also been using it for my own development branches that involve
> some systems hacking-heavy work that uses different kernel interfaces
> on all 4 of those OSes.
> 
> There's one thing I'm stuck on, though: Windows.  If anyone wants to
> help figure out how to get PostgreSQL to build on Cirrus's Windows,
> I'd be very interested.  To play with this stuff, you need a public
> Github repo, and you need to add Cirrus CI from "Marketplace" (it's
> free for public/open source), and then you add a .cirrus.yml file such
> as https://github.com/macdice/cfbot/blob/master/cirrus/.cirrus.yml to
> the top level of a PostgreSQL branch.  When you push, you should see
> build results on the Github web UI.

Is this?

> activeperl package files install completed. Performing other
> installation steps.
> ERROR: The response content cannot be parsed because the Internet
>   Explorer engine is not available, or Internet Explorer's
>   first-launch configuration is not complete. Specify the
>   UseBasicParsing parameter and try again.
> The install of activeperl was NOT successful.
> Error while running
> 'C:\ProgramData\chocolatey\lib\ActivePerl\tools\ChocolateyInstall.ps1'.
>   See log for details.

Here is the discussion on the issue.

https://github.com/MathewSachin/Captura/issues/93

> MathewSachin commented on 16 Sep 2017
> Seems to be fixed in v5.0.1.

By the way choco command on the environment says its version is:

> Chocolatey v0.10.15

It's just too old? Or I found that many articles which says that the
behavior is avoidable by setting a registory entry, but it didn't work
for me. I tried several registry paths but all of them didn't work.

reg.exe add "HKCU\SOFTWARE\Microsoft\Internet Explorer\Main" /v DisableFirstRunCustomize /t REG_DWORD /d 1 /f


> For a similar example that works on Windows on another CI, see
> https://github.com/macdice/cfbot/blob/master/appveyor/appveyor.yml
> (note that it also references a couple of other files; it'd be nice to
> be able to do that stuff without the need for separate files, possibly
> by using Power Shell).  That's what cfbot is using for Windows for
> now, which works really well, but it'd be nice to have more
> options/choices.  For another example of Windows builds working on
> another CI, see the Github Actions patch I posted earlier when I was
> considering that for cfbot[1].  I think what's different is that those
> other CIs have images with MSVC on them, but Cirrus wants you to
> figure out how to install the right toolchain yourself (and then, as a
> next step after it's actually working, it also provides a way to
> define what you want in a way that captures the resulting image using
> Docker voodoo, so that you get fast startup times).  Or something.
> 
> [1]
https://www.postgresql.org/message-id/flat/CA%2BhUKG%2By_SHVQcU3CPokmJxuHp1niebCjq4XzZizf8SR9ZdQRQ%40mail.gmail.com

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center

On 1/4/21 10:58 PM, Thomas Munro wrote:
> Hi,
>
> My new favourite CI is Cirrus CI, because it has 4 operating systems,
> generous enough quotas to handle 250+ branches in a single account,
> and public build/test log URLs.  I flipped cfbot.cputube.org (mostly)
> over to that and it seems to work well so far -- fingers crossed.
> I've also been using it for my own development branches that involve
> some systems hacking-heavy work that uses different kernel interfaces
> on all 4 of those OSes.
>
> There's one thing I'm stuck on, though: Windows.  If anyone wants to
> help figure out how to get PostgreSQL to build on Cirrus's Windows,
> I'd be very interested.  To play with this stuff, you need a public
> Github repo, and you need to add Cirrus CI from "Marketplace" (it's
> free for public/open source), and then you add a .cirrus.yml file such
> as https://github.com/macdice/cfbot/blob/master/cirrus/.cirrus.yml to
> the top level of a PostgreSQL branch.  When you push, you should see
> build results on the Github web UI.
>
> For a similar example that works on Windows on another CI, see
> https://github.com/macdice/cfbot/blob/master/appveyor/appveyor.yml
> (note that it also references a couple of other files; it'd be nice to
> be able to do that stuff without the need for separate files, possibly
> by using Power Shell).  That's what cfbot is using for Windows for
> now, which works really well, but it'd be nice to have more
> options/choices.  For another example of Windows builds working on
> another CI, see the Github Actions patch I posted earlier when I was
> considering that for cfbot[1].  I think what's different is that those
> other CIs have images with MSVC on them, but Cirrus wants you to
> figure out how to install the right toolchain yourself (and then, as a
> next step after it's actually working, it also provides a way to
> define what you want in a way that captures the resulting image using
> Docker voodoo, so that you get fast startup times).  Or something.
>
> [1]
https://www.postgresql.org/message-id/flat/CA%2BhUKG%2By_SHVQcU3CPokmJxuHp1niebCjq4XzZizf8SR9ZdQRQ%40mail.gmail.com
>
>

Here's what I use for MS Tools in automated setups, which gives you all
you should need:

    choco install -y --no-progress --limit-output
    visualstudio2019-workload-vctools --package-parameters
    "--includeOptional"

Your PATH adjustment should add this:

    C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\MSBuild\Current\bin

There might be other environment settings needed - see drongo's config on the buildfarm. LMK how you get on.

Constructing an image where you don't have to do that every build would be super nice.


cheers

andrew

--
Andrew Dunstan
EDB: https://www.enterprisedb.com

On 1/5/21 7:18 AM, Andrew Dunstan wrote:
> On 1/4/21 10:58 PM, Thomas Munro wrote:
>> Hi,
>>
>> My new favourite CI is Cirrus CI, because it has 4 operating systems,
>> generous enough quotas to handle 250+ branches in a single account,
>> and public build/test log URLs.  I flipped cfbot.cputube.org (mostly)
>> over to that and it seems to work well so far -- fingers crossed.
>> I've also been using it for my own development branches that involve
>> some systems hacking-heavy work that uses different kernel interfaces
>> on all 4 of those OSes.
>>
>> There's one thing I'm stuck on, though: Windows.  If anyone wants to
>> help figure out how to get PostgreSQL to build on Cirrus's Windows,
>> I'd be very interested.  To play with this stuff, you need a public
>> Github repo, and you need to add Cirrus CI from "Marketplace" (it's
>> free for public/open source), and then you add a .cirrus.yml file such
>> as https://github.com/macdice/cfbot/blob/master/cirrus/.cirrus.yml to
>> the top level of a PostgreSQL branch.  When you push, you should see
>> build results on the Github web UI.
>>
>> For a similar example that works on Windows on another CI, see
>> https://github.com/macdice/cfbot/blob/master/appveyor/appveyor.yml
>> (note that it also references a couple of other files; it'd be nice to
>> be able to do that stuff without the need for separate files, possibly
>> by using Power Shell).  That's what cfbot is using for Windows for
>> now, which works really well, but it'd be nice to have more
>> options/choices.  For another example of Windows builds working on
>> another CI, see the Github Actions patch I posted earlier when I was
>> considering that for cfbot[1].  I think what's different is that those
>> other CIs have images with MSVC on them, but Cirrus wants you to
>> figure out how to install the right toolchain yourself (and then, as a
>> next step after it's actually working, it also provides a way to
>> define what you want in a way that captures the resulting image using
>> Docker voodoo, so that you get fast startup times).  Or something.
>>
>> [1]
https://www.postgresql.org/message-id/flat/CA%2BhUKG%2By_SHVQcU3CPokmJxuHp1niebCjq4XzZizf8SR9ZdQRQ%40mail.gmail.com
>>
>>
> Here's what I use for MS Tools in automated setups, which gives you all
> you should need:
>
>     choco install -y --no-progress --limit-output
>     visualstudio2019-workload-vctools --package-parameters
>     "--includeOptional"
>
> Your PATH adjustment should add this:
>
>     C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\MSBuild\Current\bin
>
> There might be other environment settings needed - see drongo's config on the buildfarm. LMK how you get on.
>
> Constructing an image where you don't have to do that every build would be super nice.
>
>

OK, I have dug into this quite a bit. The way cirrus works is in fact
somewhat fragile. Anyway, here are the highlights:


The image you're using comes with these choco packages pre-installed:


    Chocolatey v0.10.15
    7zip 19.0
    7zip.install 19.0
    chocolatey 0.10.15
    chocolatey-core.extension 1.3.5.1
    chocolatey-dotnetfx.extension 1.0.1
    chocolatey-visualstudio.extension 1.8.1
    chocolatey-windowsupdate.extension 1.0.4
    cmake 3.19.1
    cmake.install 3.19.1
    dotnetfx 4.8.0.20190930
    git 2.29.2.3
    git.install 2.29.2.3
    KB2919355 1.0.20160915
    KB2919442 1.0.20160915
    KB2999226 1.0.20181019
    KB3033929 1.0.5
    KB3035131 1.0.3
    mingw 8.1.0
    vcredist140 14.28.29325.2
    visualstudio-installer 2.0.1
    visualstudio2019-workload-vctools 1.0.0
    visualstudio2019buildtools 16.8.2.0


However, sadly the vctools package above isn't installed with all its
optional packages, so some crucial things are missing. I cured that by
forcing a reinstall with the optional components enabled. Sadly, that
takes a huge amount of time, over 20 minutes. We either need to find an
image where this isn't necessary or find out how to make one to use,
assuming that's possible. Or maybe we can ask cirrus to modify their
buildscripts just a tad to include the required parameter.

The other issue I ran into was one with the ActivePerl install script. I
got around that by installing StrawberryPerl instead. It should work
fine I believe.

So here is the .cirrus.yml file I came up with. The last line fails as
expected because I have been testing in an environment without postgres
sources, but other than that it works. Note that we use VS's vcvarsall
script to set the environment properly for us.

    task:
      name: Windows
      windows_container:
        image: cirrusci/windowsservercore:cmake
      install_script:
        - choco list --localonly
        - choco install -y winflexbison diffutils
        - rename c:\ProgramData\chocolatey\bin\win_flex.exe flex.exe
        - rename c:\ProgramData\chocolatey\bin\win_bison.exe bison.exe
        - choco install -y strawberryperl
        - choco install --force -y visualstudio2019-workload-vctools
    --package-parameters "--includeOptional"
        - choco list --localonly
      build_script:
          - cd
          - set
          - cd "c:/Program Files (x86)/Microsoft Visual
    Studio/2019/BuildTools/VC/Auxiliary/Build"
          - vcvarsall x64
          - echo on
          - cd
    C:\Users\ContainerAdministrator\AppData\Local\Temp\cirrus-ci-build
          - set
          - perl -v
          - msbuild pgsql.sln

HTH


cheers


andrew


--
Andrew Dunstan
EDB: https://www.enterprisedb.com

On Wed, Jan 6, 2021 at 11:48 AM Andrew Dunstan <andrew@dunslane.net> wrote:
> OK, I have dug into this quite a bit. The way cirrus works is in fact
> somewhat fragile. Anyway, here are the highlights:

Thanks!

> However, sadly the vctools package above isn't installed with all its
> optional packages, so some crucial things are missing. I cured that by
> forcing a reinstall with the optional components enabled. Sadly, that
> takes a huge amount of time, over 20 minutes. We either need to find an
> image where this isn't necessary or find out how to make one to use,
> assuming that's possible. Or maybe we can ask cirrus to modify their
> buildscripts just a tad to include the required parameter.

Oh, thanks for the diagnosis.  This seems to be the definition of that image:

https://github.com/cirruslabs/docker-images-windows

It seems we can make our own, either on-the-fly with caching, or
hosted somewhere, like this:

https://cirrus-ci.org/guide/docker-builder-vm/#dockerfile-as-a-ci-environment

> The other issue I ran into was one with the ActivePerl install script. I
> got around that by installing StrawberryPerl instead. It should work
> fine I believe.
>
> So here is the .cirrus.yml file I came up with. The last line fails as
> expected because I have been testing in an environment without postgres
> sources, but other than that it works. Note that we use VS's vcvarsall
> script to set the environment properly for us.

>     task:
> ..

Thanks!  I hacked on this a bit more and got as far as:

C:\Users\ContainerAdministrator\AppData\Local\Temp\cirrus-ci-build>call
perl buildsetup.pl
Unable to determine Visual Studio version: The nmake version could not
be determined. at src/tools/msvc/Mkvcbuild.pm line 92.

That's from https://cirrus-ci.com/task/5842523031601152.  I guess PATH
is wrong or nmake it not present, but it's so painful to do a test
cycle that I gave up for today...

On 1/5/21 11:19 PM, Thomas Munro wrote:
>
> Thanks!  I hacked on this a bit more and got as far as:
>
> C:\Users\ContainerAdministrator\AppData\Local\Temp\cirrus-ci-build>call
> perl buildsetup.pl
> Unable to determine Visual Studio version: The nmake version could not
> be determined. at src/tools/msvc/Mkvcbuild.pm line 92.
>
> That's from https://cirrus-ci.com/task/5842523031601152.  I guess PATH
> is wrong or nmake it not present, but it's so painful to do a test
> cycle that I gave up for today...


Hmm, weird. I'll play some more tomorrow and see what I can find.


cheers


andrew


--
Andrew Dunstan
EDB: https://www.enterprisedb.com

On 1/6/21 12:36 AM, Andrew Dunstan wrote:
> On 1/5/21 11:19 PM, Thomas Munro wrote:
>> Thanks!  I hacked on this a bit more and got as far as:
>>
>> C:\Users\ContainerAdministrator\AppData\Local\Temp\cirrus-ci-build>call
>> perl buildsetup.pl
>> Unable to determine Visual Studio version: The nmake version could not
>> be determined. at src/tools/msvc/Mkvcbuild.pm line 92.
>>
>> That's from https://cirrus-ci.com/task/5842523031601152.  I guess PATH
>> is wrong or nmake it not present, but it's so painful to do a test
>> cycle that I gave up for today...
>
> Hmm, weird. I'll play some more tomorrow and see what I can find.


I have it building and testing ok, but it's horribly fragile. I doubt
this is acceptable for the cfbot, you'll get far to many spurious failures.


There are some build warnings we don't usually see. I haven't delved
into that.


See <https://cirrus-ci.com/task/4602736530423808>


The yml file is:


    task:
      name: Windows
      windows_container:
        image: cirrusci/windowsservercore:cmake
      install_script:
        - choco feature disable --name=showDownloadProgress
        - choco install -y winflexbison diffutils
        - rename c:\ProgramData\chocolatey\bin\win_flex.exe flex.exe
        - rename c:\ProgramData\chocolatey\bin\win_bison.exe bison.exe
        - choco install -y strawberryperl
        - choco install --force -y visualstudio2019-workload-vctools --package-parameters "--includeOptional"
        - choco list --localonly
      build_script:
        - cd "c:/Program Files (x86)/Microsoft Visual Studio/2019/BuildTools/VC/Auxiliary/Build"
        - vcvarsall x64
        - echo on
        - cd C:\Users\ContainerAdministrator\AppData\Local\Temp\cirrus-ci-build
        - set PATH=C:\strawberry\perl\bin;%PATH%
        - set
        - perl src/tools/msvc/mkvcbuild.pl
        - msbuild pgsql.sln
      test_script:
        - set PATH=C:\strawberry\perl\bin;%PATH%
        - set
        - perl src/tools/msvc/vcregress.pl check


cheers


andrew


--
Andrew Dunstan
EDB: https://www.enterprisedb.com

On 1/5/21 5:48 PM, I wrote:
> However, sadly the vctools package above isn't installed with all its
> optional packages, so some crucial things are missing. I cured that by
> forcing a reinstall with the optional components enabled. Sadly, that
> takes a huge amount of time, over 20 minutes. We either need to find an
> image where this isn't necessary or find out how to make one to use,
> assuming that's possible. Or maybe we can ask cirrus to modify their
> buildscripts just a tad to include the required parameter.


For some unfathomable reason they actually removed this less than a
month ago:

<https://github.com/cirruslabs/docker-images-windows/commit/6777ec66b76747a88f61252f9027f70d23fcc4ce>

I have identified the specific missing component as
Microsoft.VisualStudio.Component.VC.CLI.Support - I will submit a PR to
add it back in.


cheers


andrew

--
Andrew Dunstan
EDB: https://www.enterprisedb.com

On 1/5/21 11:19 PM, Thomas Munro wrote:
>
> It seems we can make our own, either on-the-fly with caching, or
> hosted somewhere, like this:
>
> https://cirrus-ci.org/guide/docker-builder-vm/#dockerfile-as-a-ci-environment
>
>


OK, I got this working.


There is some weirdness that I had to work around in the way they do
docker. So here's what works for me, with the docker image nicely cached
even across repos:


.cirrus.yml:

    task:
      name: Windows
      windows_container:
        dockerfile: ci/Dockerfile
      build_script:
          - cd "c:/Program Files (x86)/Microsoft Visual Studio/2019/BuildTools/VC/Auxiliary/Build"
          - vcvarsall x64
          - echo on
          - cd C:\Users\ContainerAdministrator\AppData\Local\Temp\cirrus-ci-build
          - set PATH=C:\strawberry\perl\bin;%PATH%
          - perl src/tools/msvc/mkvcbuild.pl
          - set IgnoreWarnIntDirInTempDetected=true
          - msbuild pgsql.sln
      test_script:
          - set PATH=C:\strawberry\perl\bin;%PATH%
          - perl src/tools/msvc/vcregress.pl check


ci/Dockerfile:

    FROM cirrusci/windowsservercore:2019

    SHELL ["powershell", "-NoLogo", "-NoProfile", "-Command"]


    RUN \
        pwd ; \
        choco feature disable -n=usePackageExitCodes ; \
        choco install -y --no-progress --version=16.8.3.0 visualstudio2019buildtools


    # cirrus does something odd with this command, so it's stuck in a bat file
    # and copied to the docker container and then executed
    COPY ci/inst-tools.bat .
    RUN \
        cmd /c .\inst-tools.bat

    RUN \
        choco install -y --no-progress strawberryperl ; \
        choco install -y --no-progress winflexbison diffutils ; \
        Rename-Item -Path c:\ProgramData\chocolatey\bin\win_flex.exe flex.exe ; \
        Rename-Item -Path c:\ProgramData\chocolatey\bin\win_bison.exe bison.exe ; \
        Remove-Item C:\ProgramData\chocolatey\logs\*.* -Force -Recurse ; \
        Remove-Item C:\Users\ContainerAdministrator\AppData\Local\Temp\*.* -Force -Recurse

ci/inst-tools.bat:

    choco install -y --no-progress --version=1.0.0 visualstudio2019-workload-vctools  --install-args="--add
Microsoft.VisualStudio.Component.VC.CLI.Support"

cheers


andrew


--
Andrew Dunstan
EDB: https://www.enterprisedb.com

On Wed, Jan 13, 2021 at 3:04 AM Andrew Dunstan <andrew@dunslane.net> wrote:
> OK, I got this working.

Thanks Andrew.  This is great!

>     # cirrus does something odd with this command, so it's stuck in a bat file
>     # and copied to the docker container and then executed
>     COPY ci/inst-tools.bat .
>     RUN \
>         cmd /c .\inst-tools.bat

Huh, weird.  Must have been painful to figure out.  The Docker image
step took 42 minutes for me so I shudder to think how the
trial-and-error process went.  But now that it's working and cached,
build jobs start up nice and fast, so that's some great progress.

I'm experimenting with this on my own development branches for now,
and will see what else I can improve.  Then maybe I'll change the
cfbot over after the commitfest.  (Also got to get macOS doing
check-world, and Linux using a fast-start Docker image.)

Hi,

On Tue, Jan 12, 2021 at 09:04:51AM -0500, Andrew Dunstan wrote:
> On 1/5/21 11:19 PM, Thomas Munro wrote:
> >
> > It seems we can make our own, either on-the-fly with caching, or
> > hosted somewhere, like this:
> >
> > https://cirrus-ci.org/guide/docker-builder-vm/#dockerfile-as-a-ci-environment
> 
> OK, I got this working.

I tried this to use the "dockerfile-as-a-ci-environment" process, to see if it
would allow cirrus to start windows builds without the 4 minute delay that we
currently have.

But it failed like:

https://cirrus-ci.com/task/5622728425209856?logs=push#L16
[00:09:53.675] unauthorized: You don't have the needed permissions to perform this operation, and you may have invalid
credentials.To authenticate your request, follow the steps in:
 
https://cloud.google.com/container-registry/docs/advanced-authentication

Does this require tying my github account to a google account ?
Or paying cirrusci ?  Or ??

-- 
Justin

Hi,

On 2022-07-28 19:49:43 -0500, Justin Pryzby wrote:
> On Tue, Jan 12, 2021 at 09:04:51AM -0500, Andrew Dunstan wrote:
> > On 1/5/21 11:19 PM, Thomas Munro wrote:
> > >
> > > It seems we can make our own, either on-the-fly with caching, or
> > > hosted somewhere, like this:
> > >
> > > https://cirrus-ci.org/guide/docker-builder-vm/#dockerfile-as-a-ci-environment
> > 
> > OK, I got this working.
> 
> I tried this to use the "dockerfile-as-a-ci-environment" process, to see if it
> would allow cirrus to start windows builds without the 4 minute delay that we
> currently have.

I don't see how it'd fix that delay - the delay is from pulling down the
docker container onto the host. That's independent of the method of building
the container. The only thing making this faster is reducing the size of the
docker container. There's a bunch we could do on that front - e.g. removing
arm specific tools and debug symbols from the various layers (afaict there's
no option not to install them).

We could try to transition to using full VMs instead of docker containers (gcp
fetches the image data on demand instead of ahead-of-time), but that'd likely
be nontrivial due to licensing etc.


> But it failed like:
> 
> https://cirrus-ci.com/task/5622728425209856?logs=push#L16
> [00:09:53.675] unauthorized: You don't have the needed permissions to perform this operation, and you may have
invalidcredentials. To authenticate your request, follow the steps in:
 
> https://cloud.google.com/container-registry/docs/advanced-authentication
> 
> Does this require tying my github account to a google account ?
> Or paying cirrusci ?  Or ??

Not sure what the problem here is - it worked for me in the past.

Greetings,

Andres Freund

On Sun, Jul 31, 2022 at 01:31:58PM -0700, Andres Freund wrote:
> > But it failed like:
> > 
> > https://cirrus-ci.com/task/5622728425209856?logs=push#L16
> > [00:09:53.675] unauthorized: You don't have the needed permissions to perform this operation, and you may have
invalidcredentials. To authenticate your request, follow the steps in:
 
> > https://cloud.google.com/container-registry/docs/advanced-authentication
> > 
> > Does this require tying my github account to a google account ?
> > Or paying cirrusci ?  Or ??
> 
> Not sure what the problem here is - it worked for me in the past.

I reported the problem to Fedor at cirrusci who had to fix something.
It works now.

On Wed, Aug 03, 2022 at 09:06:05PM -0700, Andres Freund wrote:
> On 2022-07-28 17:23:19 -0500, Justin Pryzby wrote:
> > I think it could be a lot faster to start, since cirrus caches the generated
> > docker image locally.  Rather than (I gather) pulling the image every time.
> 
> I'm quite certain that is not true. All the docker images built are just
> uploaded to the google container registry and then downloaded onto a
> *separate* windows host. The dockerfile: stuff generates a separate task
> running on a separate machine...

I think you're right.  When I used an image built with with Andrew's original
recipe using "dockerfile-as-a-ci-environment" , it still took ~4+ minutes to
start.

Note that there's now a cirrusci image with visual studio 2022, which allows
building postgres.  I tried it here.
https://cirrus-ci.com/task/4939320325832704
Scheduled in 01:19

It makes sense that that's faster since it has none of the goodies or
postgres-specific stuff in your image: debugging tools, perl, python, flex,
bison, ssl, zlib, ICU...

But look: https://cirrus-ci.com/task/4953593575899136

=> I installed most of the goodies, but deferred running the installers until
the image is run, and it starts just as quickly.  It has to run the installer
each time, rather than once when building the image.  That's crummy, but it's
still 1-2 minutes faster than now.  Maybe for some of those, it's not needed to
run an installer at all.  (Like if the installer can be extracted into
c:\programfiles).

-- 
Justin

Hi,

On 2022-08-18 19:56:56 -0500, Justin Pryzby wrote:
> Note that there's now a cirrusci image with visual studio 2022, which allows
> building postgres.  I tried it here.

In the past there were repeated issues with the cirrus install of visual
studio missing some things, and modifying the install to install them was very
slow, that's why I had switched to installing VS ourselves.

I suspect that the other issue right now is that they updated the host to
a newer version of windows, and when container and host version don't match,
the windows container stuff gets slower starting up.


> But look: https://cirrus-ci.com/task/4953593575899136

Why is the build phase so slow in that image? 12min? That's way slower than
the windows builds normally.


> => I installed most of the goodies, but deferred running the installers until
> the image is run, and it starts just as quickly.  It has to run the installer
> each time, rather than once when building the image.  That's crummy, but it's
> still 1-2 minutes faster than now.  Maybe for some of those, it's not needed to
> run an installer at all.  (Like if the installer can be extracted into
> c:\programfiles).

I am strongly against that. For one, the amount of traffic that causes with
the software providers is substantial. For another, the failure rates of
downloading stuff every time are quite high.

I think pruning the container from unnecessary content, and trying to base it
on the vs 2022 image (which is prel-loaded onto the host) is a better plan.

Greetings,

Andres Freund

On Thu, Aug 18, 2022 at 06:09:39PM -0700, Andres Freund wrote:
> > But look: https://cirrus-ci.com/task/4953593575899136
> 
> Why is the build phase so slow in that image? 12min? That's way slower than
> the windows builds normally.

Because I'd just rebased it, and it's using ccache, which I mentioned is
several times slower for cache misses, and only ~50% faster for cache hits :(
20220701191841.GH13040@telsasoft.com

There's a patch to use depend mode, which would make cache misses less
expensive.

> > => I installed most of the goodies, but deferred running the installers until
> > the image is run, and it starts just as quickly.  It has to run the installer
> > each time, rather than once when building the image.  That's crummy, but it's
> > still 1-2 minutes faster than now.  Maybe for some of those, it's not needed to
> > run an installer at all.  (Like if the installer can be extracted into
> > c:\programfiles).
> 
> I am strongly against that. For one, the amount of traffic that causes with
> the software providers is substantial. For another, the failure rates of
> downloading stuff every time are quite high.

I think you misunderstood.  The installers are *retrieved* when the image is
built, and zipfiles are extracted.  But for .exes, the installation is deferred
until the image is run.

-- 
Justin

Hi,

On 2022-08-18 20:17:09 -0500, Justin Pryzby wrote:
> On Thu, Aug 18, 2022 at 06:09:39PM -0700, Andres Freund wrote:
> > > But look: https://cirrus-ci.com/task/4953593575899136
> > 
> > Why is the build phase so slow in that image? 12min? That's way slower than
> > the windows builds normally.
> 
> Because I'd just rebased it, and it's using ccache, which I mentioned is
> several times slower for cache misses, and only ~50% faster for cache hits :(
> 20220701191841.GH13040@telsasoft.com

That makes it basically unusable - builds being that slow even just
occasionally is prohibitive for something like cfbot I think.

I'm a bit surprised though - I'm fairly certain that that wasn't the case when
I tried it locally (with ninja at least).


> > > => I installed most of the goodies, but deferred running the installers until
> > > the image is run, and it starts just as quickly.  It has to run the installer
> > > each time, rather than once when building the image.  That's crummy, but it's
> > > still 1-2 minutes faster than now.  Maybe for some of those, it's not needed to
> > > run an installer at all.  (Like if the installer can be extracted into
> > > c:\programfiles).
> > 
> > I am strongly against that. For one, the amount of traffic that causes with
> > the software providers is substantial. For another, the failure rates of
> > downloading stuff every time are quite high.
> 
> I think you misunderstood.  The installers are *retrieved* when the image is
> built, and zipfiles are extracted.  But for .exes, the installation is deferred
> until the image is run.

Ah, that's better.

I still think it's better to not install things every time and reduce the
install footprint though.

Greetings,

Andres Freund