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]/messages/by-id/CA+hUKG+y_SHVQcU3CPokmJxuHp1niebCjq4XzZizf8SR9ZdQRQ@mail.gmail.com. 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]: /messages/by-id/CA+hUKG+y_SHVQcU3CPokmJxuHp1niebCjq4XzZizf8SR9ZdQRQ@mail.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] /messages/by-id/CA+hUKG+y_SHVQcU3CPokmJxuHp1niebCjq4XzZizf8SR9ZdQRQ@mail.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] /messages/by-id/CA+hUKG+y_SHVQcU3CPokmJxuHp1niebCjq4XzZizf8SR9ZdQRQ@mail.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] /messages/by-id/CA+hUKG+y_SHVQcU3CPokmJxuHp1niebCjq4XzZizf8SR9ZdQRQ@mail.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:
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 invalid credentials. To authenticate your request, follow the steps in:
https://cloud.google.com/container-registry/docs/advanced-authenticationDoes 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