Update Windows CI Task Names: Server 2022 + VS 2022 Upgrade
Hi,
Thomas Munro off-list mentioned that the Windows CI image is actually
running on Server 2022, even though the task name still refers to
Server 2019. He also suggested upgrading the compiler from Visual
Studio 2019 to Visual Studio 2022.
A PR [1]https://github.com/anarazel/pg-vm-images/pull/114 to upgrade the compiler to VS 2022 is ready in Andres'
pg-vm-images repository (where the CI images are built). This VS 2022
image passes all tests for both MinGW [2]https://cirrus-ci.com/build/5095727501672448 and Meson & Ninja [2]https://cirrus-ci.com/build/5095727501672448. Once
it's merged, the CI images will automatically start using the VS 2022
compiler.
Two patches are attached, the first one is for fixing server names and
the second one is for upgrading the VS compiler version in the task
name. Please note: the PR and second patch should be committed
simultaneously to avoid mismatches (e.g., a VS 2019 task running with
a VS 2022 compiler, or vice versa).
Any feedback would be appreciated.
[1]: https://github.com/anarazel/pg-vm-images/pull/114
[2]: https://cirrus-ci.com/build/5095727501672448
--
Regards,
Nazir Bilal Yavuz
Microsoft
Attachments:
0001-ci-Update-Windows-task-names-to-reflect-Server-2022.patchtext/x-patch; charset=US-ASCII; name=0001-ci-Update-Windows-task-names-to-reflect-Server-2022.patchDownload
From 8bb0ba7db2cd56cf8d459b90df3643a8ee31c346 Mon Sep 17 00:00:00 2001
From: Nazir Bilal Yavuz <byavuz81@gmail.com>
Date: Thu, 5 Jun 2025 10:29:06 +0300
Subject: [PATCH 1/2] ci: Update Windows task names to reflect Server 2022
The Windows CI image has been running on Server 2022 for some time,
but task names still referred to Server 2019.
Reported-by: Thomas Munro <thomas.munro@gmail.com>
---
.cirrus.tasks.yml | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/.cirrus.tasks.yml b/.cirrus.tasks.yml
index 92057006c93..0616cb71a00 100644
--- a/.cirrus.tasks.yml
+++ b/.cirrus.tasks.yml
@@ -701,7 +701,7 @@ WINDOWS_ENVIRONMENT_BASE: &WINDOWS_ENVIRONMENT_BASE
task:
- name: Windows - Server 2019, VS 2019 - Meson & ninja
+ name: Windows - Server 2022, VS 2019 - Meson & ninja
<< : *WINDOWS_ENVIRONMENT_BASE
env:
@@ -753,7 +753,7 @@ task:
task:
<< : *WINDOWS_ENVIRONMENT_BASE
- name: Windows - Server 2019, MinGW64 - Meson
+ name: Windows - Server 2022, MinGW64 - Meson
# due to resource constraints we don't run this task by default for now
trigger_type: manual
--
2.49.0
0002-ci-Update-Windows-task-name-to-reflect-VS-2022.patchtext/x-patch; charset=US-ASCII; name=0002-ci-Update-Windows-task-name-to-reflect-VS-2022.patchDownload
From f9b789fa128f8cd3c39550a81659bb3e0aa9440e Mon Sep 17 00:00:00 2001
From: Nazir Bilal Yavuz <byavuz81@gmail.com>
Date: Thu, 5 Jun 2025 10:31:37 +0300
Subject: [PATCH 2/2] ci: Update Windows task name to reflect VS 2022
With the compiler being upgraded to Visual Studio 2022 (see related PR
[1]), update the task name to accurately describe the environment.
[1] https://github.com/anarazel/pg-vm-images/pull/114
Suggested-by: Thomas Munro <thomas.munro@gmail.com>
---
.cirrus.tasks.yml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/.cirrus.tasks.yml b/.cirrus.tasks.yml
index 0616cb71a00..d6dfa52e4cf 100644
--- a/.cirrus.tasks.yml
+++ b/.cirrus.tasks.yml
@@ -701,7 +701,7 @@ WINDOWS_ENVIRONMENT_BASE: &WINDOWS_ENVIRONMENT_BASE
task:
- name: Windows - Server 2022, VS 2019 - Meson & ninja
+ name: Windows - Server 2022, VS 2022 - Meson & ninja
<< : *WINDOWS_ENVIRONMENT_BASE
env:
--
2.49.0
On 05.06.25 10:04, Nazir Bilal Yavuz wrote:
Thomas Munro off-list mentioned that the Windows CI image is actually
running on Server 2022, even though the task name still refers to
Server 2019. He also suggested upgrading the compiler from Visual
Studio 2019 to Visual Studio 2022.
Some of the tasks for the other operating systems name the version, some
don't. We have recently removed the version from the FreeBSD task.
Should we remove the versions from the task name everywhere, to avoid
having further mismatches?
A PR [1] to upgrade the compiler to VS 2022 is ready in Andres'
pg-vm-images repository (where the CI images are built). This VS 2022
image passes all tests for both MinGW [2] and Meson & Ninja [2]. Once
it's merged, the CI images will automatically start using the VS 2022
compiler.
Hmm, for the purposes of [0]/messages/by-id/01a69441-af54-4822-891b-ca28e05b215a@eisentraut.org, I think it might be better to keep the
image at VS 2019 for now. Unless there are specific reasons why VS 2022
would be of use now?
[0]: /messages/by-id/01a69441-af54-4822-891b-ca28e05b215a@eisentraut.org
/messages/by-id/01a69441-af54-4822-891b-ca28e05b215a@eisentraut.org
Hi,
On Thu, 5 Jun 2025 at 11:27, Peter Eisentraut <peter@eisentraut.org> wrote:
On 05.06.25 10:04, Nazir Bilal Yavuz wrote:
Thomas Munro off-list mentioned that the Windows CI image is actually
running on Server 2022, even though the task name still refers to
Server 2019. He also suggested upgrading the compiler from Visual
Studio 2019 to Visual Studio 2022.Some of the tasks for the other operating systems name the version, some
don't. We have recently removed the version from the FreeBSD task.
Should we remove the versions from the task name everywhere, to avoid
having further mismatches?
I think one of the biggest advantages of having a version in the task
name is immediately seeing if something is updated (without checking
-hackers or sysinfo). However, most of the information is already
available in the sysinfo in the task and since we removed the version
from FreeBSD; I think we can remove it from all of the tasks.
A PR [1] to upgrade the compiler to VS 2022 is ready in Andres'
pg-vm-images repository (where the CI images are built). This VS 2022
image passes all tests for both MinGW [2] and Meson & Ninja [2]. Once
it's merged, the CI images will automatically start using the VS 2022
compiler.Hmm, for the purposes of [0], I think it might be better to keep the
image at VS 2019 for now. Unless there are specific reasons why VS 2022
would be of use now?
Thomas was thinking of trying some new APIs which are available in the
VS 2022, he may answer this better.
--
Regards,
Nazir Bilal Yavuz
Microsoft
On Thu, Jun 5, 2025 at 8:48 PM Nazir Bilal Yavuz <byavuz81@gmail.com> wrote:
Hmm, for the purposes of [0], I think it might be better to keep the
image at VS 2019 for now. Unless there are specific reasons why VS 2022
would be of use now?Thomas was thinking of trying some new APIs which are available in the
VS 2022, he may answer this better.
My goal in asking about that was to have the infrastructure to advance
the Windows-on-aarch64 project (as a non-Windows developer trying to
advance things based on standards instead of hand-rolling), since
that's apparently where their <stdatomic.h> support was added, and I
speculate that that is the best way forward for porting our atomics to
new platforms:
/messages/by-id/CADK3HHL9hJnCxttPnhPvdNdXC_7ger=iarMMy0KOrOOweaMAxw@mail.gmail.com
I think on your C11 thread I might have been confused about that,
since there was an implication that 2019 might support <stdatomic.h>,
but it looks like 2019 added language stuff while 2022 added the
library stuff. But yeah, given your proposal that MSVC 2019 should be
our new minimum target on that platform, I wonder if we should have
both available in CI somehow...
(Trying to constrain the window of MSVC support to just "the two
latest major releases" in future is also an attractive idea, as seen
in some other big open source C/C++ projects, given our lack of
Windows-native developers and reliance on CI, but let's call that a
separate debate.)
On 05.06.25 12:42, Thomas Munro wrote:
I think on your C11 thread I might have been confused about that,
since there was an implication that 2019 might support <stdatomic.h>,
but it looks like 2019 added language stuff while 2022 added the
library stuff. But yeah, given your proposal that MSVC 2019 should be
our new minimum target on that platform, I wonder if we should have
both available in CI somehow...
It would be useful to have a leading and a trailing edge CI system for
every OS family. For example, say, Ubuntu 25.04 and RHEL 7, and VS 201x
and VS 202y. Because as we are seeing here, sometimes you're more
concerned about breaking the old one, and sometimes you're more
interested in using a feature on the new one. Maybe one of the two
could be manually triggered to save on resources.
Hi,
On Fri, 6 Jun 2025 at 08:30, Peter Eisentraut <peter@eisentraut.org> wrote:
On 05.06.25 12:42, Thomas Munro wrote:
I think on your C11 thread I might have been confused about that,
since there was an implication that 2019 might support <stdatomic.h>,
but it looks like 2019 added language stuff while 2022 added the
library stuff. But yeah, given your proposal that MSVC 2019 should be
our new minimum target on that platform, I wonder if we should have
both available in CI somehow...It would be useful to have a leading and a trailing edge CI system for
every OS family. For example, say, Ubuntu 25.04 and RHEL 7, and VS 201x
and VS 202y. Because as we are seeing here, sometimes you're more
concerned about breaking the old one, and sometimes you're more
interested in using a feature on the new one. Maybe one of the two
could be manually triggered to save on resources.
I think that is pretty doable. First we need to decide on a list of OS
families, though.
--
Regards,
Nazir Bilal Yavuz
Microsoft
Hi,
On Fri, 6 Jun 2025 at 08:30, Peter Eisentraut <peter@eisentraut.org> wrote:
On 05.06.25 12:42, Thomas Munro wrote:
I think on your C11 thread I might have been confused about that,
since there was an implication that 2019 might support <stdatomic.h>,
but it looks like 2019 added language stuff while 2022 added the
library stuff. But yeah, given your proposal that MSVC 2019 should be
our new minimum target on that platform, I wonder if we should have
both available in CI somehow...It would be useful to have a leading and a trailing edge CI system for
every OS family. For example, say, Ubuntu 25.04 and RHEL 7, and VS 201x
and VS 202y. Because as we are seeing here, sometimes you're more
concerned about breaking the old one, and sometimes you're more
interested in using a feature on the new one. Maybe one of the two
could be manually triggered to save on resources.
I have a PR [1]https://github.com/anarazel/pg-vm-images/pull/116 for installing both VS 2022 and VS 2019 to the Windows
CI image. And here is the patch for enabling both VS 2022 and VS 2019
Windows CI tasks. Since VS 2022 is the newer one, I made it triggered
automatically. VS 2019 task is manually triggered now.
Tasks have short names to select them and the 'Windows VS 2019' task's
name was 'windows' (i.e: ci-os-only: windows) but since we have two
Windows tasks now; we need to have different names for VS 2019 and VS
2022 tasks. To preserve the same behavior, VS 2022 task uses 'windows'
but VS 2019 is renamed to 'vs2019' (i.e: ci-os-only: vs2019). I am not
completely convinced about this naming, I am open to suggestions.
Notes: This new Windows CI image is not used for now, it will be used
when this PR [1]https://github.com/anarazel/pg-vm-images/pull/116 is merged. So,
1- To test these changes, you need to apply 0001. 0001 forces CI to
use the Windows CI image with both VS versions installed. 0001 should
not be committed.
2- To avoid confusions, 0002 patch needs to be committed immediately
after 'the PR [1]https://github.com/anarazel/pg-vm-images/pull/116 is merged and the new Windows CI image is
generated'.
Example CI task after the PR is merged and 0002 is committed:
https://cirrus-ci.com/build/5976334188412928 (I manually triggered the
VS 2019 task, it will not be run automatically after the 0002 is
committed).
[1]: https://github.com/anarazel/pg-vm-images/pull/116
--
Regards,
Nazir Bilal Yavuz
Microsoft
Attachments:
v2-0001-Force-using-Windows-CI-image-with-both-VS-version.patchtext/x-patch; charset=US-ASCII; name=v2-0001-Force-using-Windows-CI-image-with-both-VS-version.patchDownload
From 9eceff42445a753182c80985a7d89b445d30383c Mon Sep 17 00:00:00 2001
From: Nazir Bilal Yavuz <byavuz81@gmail.com>
Date: Thu, 4 Sep 2025 14:47:04 +0300
Subject: [PATCH v2 1/2] Force using Windows CI image with both VS versions
installed
This patch should not be committed, only for testing!
---
.cirrus.yml | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/.cirrus.yml b/.cirrus.yml
index 3f75852e84e..87085266ec2 100644
--- a/.cirrus.yml
+++ b/.cirrus.yml
@@ -74,7 +74,12 @@ default_openbsd_task_template: &openbsd_task_template
default_windows_task_template: &windows_task_template
env:
PLATFORM: windows
- <<: *cirrus_community_vm_template
+ compute_engine_instance:
+ image_project: pg-ci-images-dev
+ image: pg-ci-windows-ci-2025-09-08t07-40-48
+ platform: $PLATFORM
+ cpu: $CPUS
+ disk: $DISK_SIZE
# macos workers provided by cirrus-ci
--
2.51.0
v2-0002-ci-windows-Default-to-VS-2022-run-VS-2019-task-ma.patchtext/x-patch; charset=US-ASCII; name=v2-0002-ci-windows-Default-to-VS-2022-run-VS-2019-task-ma.patchDownload
From 0864e225c62f48eae2201573d40cff026c6b470e Mon Sep 17 00:00:00 2001
From: Nazir Bilal Yavuz <byavuz81@gmail.com>
Date: Thu, 4 Sep 2025 17:20:18 +0300
Subject: [PATCH v2 2/2] ci: windows: Default to VS 2022, run VS 2019 task
manually
Both VS 2019 and VS 2022 are available on the Windows image [1], but
since VS 2022 is the latest version, make it the default. The VS 2019
task is still available but must be triggered manually.
[1] https://github.com/anarazel/pg-vm-images/pull/116
Author: Nazir Bilal Yavuz <byavuz81@gmail.com>
Discussion: https://postgr.es/m/flat/CAN55FZ1OsaM+852BMQDJ+Kgfg+07knJ6dM3PjbGbtYaK4qwfqA@mail.gmail.com
---
.cirrus.star | 3 ++-
.cirrus.tasks.yml | 14 ++++++++++++--
2 files changed, 14 insertions(+), 3 deletions(-)
diff --git a/.cirrus.star b/.cirrus.star
index e9bb672b959..cecd9bb026c 100644
--- a/.cirrus.star
+++ b/.cirrus.star
@@ -73,7 +73,7 @@ def compute_environment_vars():
# REPO_CI_AUTOMATIC_TRIGGER_TASKS="task_name other_task" under "Repository
# Settings" on Cirrus CI's website.
- default_manual_trigger_tasks = ['mingw', 'netbsd', 'openbsd']
+ default_manual_trigger_tasks = ['mingw', 'netbsd', 'openbsd', 'vs2019']
repo_ci_automatic_trigger_tasks = env.get('REPO_CI_AUTOMATIC_TRIGGER_TASKS', '')
for task in default_manual_trigger_tasks:
@@ -103,6 +103,7 @@ def compute_environment_vars():
'netbsd',
'openbsd',
'sanitycheck',
+ 'vs2019',
'windows',
]
commit_message = env.get('CIRRUS_CHANGE_MESSAGE')
diff --git a/.cirrus.tasks.yml b/.cirrus.tasks.yml
index eca9d62fc22..07e32b588ea 100644
--- a/.cirrus.tasks.yml
+++ b/.cirrus.tasks.yml
@@ -752,7 +752,6 @@ WINDOWS_ENVIRONMENT_BASE: &WINDOWS_ENVIRONMENT_BASE
task:
- name: Windows - Server 2019, VS 2019 - Meson & ninja
<< : *WINDOWS_ENVIRONMENT_BASE
env:
@@ -775,10 +774,21 @@ task:
-Dplperl=enabled
-Dplpython=enabled
+ matrix:
+ - name: Windows - Server 2022, VS 2019 - Meson & ninja
+ env:
+ # Use VS 2019
+ PATH: C:\VS_2019\VC\Auxiliary\Build;${PATH}
+ trigger_type: $CI_TRIGGER_TYPE_VS2019
+ only_if: $CI_VS2019_ENABLED
+
+ # VS 2022 is the default VS installation
+ - name: Windows - Server 2022, VS 2022 - Meson & ninja
+ only_if: $CI_WINDOWS_ENABLED
+
<<: *windows_task_template
depends_on: SanityCheck
- only_if: $CI_WINDOWS_ENABLED
setup_additional_packages_script: |
REM choco install -y --no-progress ...
--
2.51.0
Hi,
On Mon, 8 Sept 2025 at 11:25, Nazir Bilal Yavuz <byavuz81@gmail.com> wrote:
Example CI task after the PR is merged and 0002 is committed:
https://cirrus-ci.com/build/5976334188412928 (I manually triggered the
VS 2019 task, it will not be run automatically after the 0002 is
committed).
I forgot to update src/tools/ci/README in the v2, v3 is attached.
--
Regards,
Nazir Bilal Yavuz
Microsoft
Attachments:
v3-0001-Force-using-Windows-CI-image-with-both-VS-version.patchtext/x-patch; charset=US-ASCII; name=v3-0001-Force-using-Windows-CI-image-with-both-VS-version.patchDownload
From f9532eeac988735b02a78847ff6ba5139de546a8 Mon Sep 17 00:00:00 2001
From: Nazir Bilal Yavuz <byavuz81@gmail.com>
Date: Thu, 4 Sep 2025 14:47:04 +0300
Subject: [PATCH v3 1/2] Force using Windows CI image with both VS versions
installed
This patch should not be committed, only for testing!
---
.cirrus.yml | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/.cirrus.yml b/.cirrus.yml
index 3f75852e84e..87085266ec2 100644
--- a/.cirrus.yml
+++ b/.cirrus.yml
@@ -74,7 +74,12 @@ default_openbsd_task_template: &openbsd_task_template
default_windows_task_template: &windows_task_template
env:
PLATFORM: windows
- <<: *cirrus_community_vm_template
+ compute_engine_instance:
+ image_project: pg-ci-images-dev
+ image: pg-ci-windows-ci-2025-09-08t07-40-48
+ platform: $PLATFORM
+ cpu: $CPUS
+ disk: $DISK_SIZE
# macos workers provided by cirrus-ci
--
2.51.0
v3-0002-ci-windows-Default-to-VS-2022-run-VS-2019-task-ma.patchtext/x-patch; charset=US-ASCII; name=v3-0002-ci-windows-Default-to-VS-2022-run-VS-2019-task-ma.patchDownload
From 77ba9eaf85ba2b3304d85caa86ee371541df2c72 Mon Sep 17 00:00:00 2001
From: Nazir Bilal Yavuz <byavuz81@gmail.com>
Date: Thu, 4 Sep 2025 17:20:18 +0300
Subject: [PATCH v3 2/2] ci: windows: Default to VS 2022, run VS 2019 task
manually
Both VS 2019 and VS 2022 are available on the Windows image [1], but
since VS 2022 is the latest version, make it the default. The VS 2019
task is still available but must be triggered manually.
[1] https://github.com/anarazel/pg-vm-images/pull/116
Author: Nazir Bilal Yavuz <byavuz81@gmail.com>
Discussion: https://postgr.es/m/flat/CAN55FZ1OsaM+852BMQDJ+Kgfg+07knJ6dM3PjbGbtYaK4qwfqA@mail.gmail.com
---
.cirrus.star | 3 ++-
.cirrus.tasks.yml | 14 ++++++++++++--
src/tools/ci/README | 4 ++--
3 files changed, 16 insertions(+), 5 deletions(-)
diff --git a/.cirrus.star b/.cirrus.star
index e9bb672b959..cecd9bb026c 100644
--- a/.cirrus.star
+++ b/.cirrus.star
@@ -73,7 +73,7 @@ def compute_environment_vars():
# REPO_CI_AUTOMATIC_TRIGGER_TASKS="task_name other_task" under "Repository
# Settings" on Cirrus CI's website.
- default_manual_trigger_tasks = ['mingw', 'netbsd', 'openbsd']
+ default_manual_trigger_tasks = ['mingw', 'netbsd', 'openbsd', 'vs2019']
repo_ci_automatic_trigger_tasks = env.get('REPO_CI_AUTOMATIC_TRIGGER_TASKS', '')
for task in default_manual_trigger_tasks:
@@ -103,6 +103,7 @@ def compute_environment_vars():
'netbsd',
'openbsd',
'sanitycheck',
+ 'vs2019',
'windows',
]
commit_message = env.get('CIRRUS_CHANGE_MESSAGE')
diff --git a/.cirrus.tasks.yml b/.cirrus.tasks.yml
index eca9d62fc22..07e32b588ea 100644
--- a/.cirrus.tasks.yml
+++ b/.cirrus.tasks.yml
@@ -752,7 +752,6 @@ WINDOWS_ENVIRONMENT_BASE: &WINDOWS_ENVIRONMENT_BASE
task:
- name: Windows - Server 2019, VS 2019 - Meson & ninja
<< : *WINDOWS_ENVIRONMENT_BASE
env:
@@ -775,10 +774,21 @@ task:
-Dplperl=enabled
-Dplpython=enabled
+ matrix:
+ - name: Windows - Server 2022, VS 2019 - Meson & ninja
+ env:
+ # Use VS 2019
+ PATH: C:\VS_2019\VC\Auxiliary\Build;${PATH}
+ trigger_type: $CI_TRIGGER_TYPE_VS2019
+ only_if: $CI_VS2019_ENABLED
+
+ # VS 2022 is the default VS installation
+ - name: Windows - Server 2022, VS 2022 - Meson & ninja
+ only_if: $CI_WINDOWS_ENABLED
+
<<: *windows_task_template
depends_on: SanityCheck
- only_if: $CI_WINDOWS_ENABLED
setup_additional_packages_script: |
REM choco install -y --no-progress ...
diff --git a/src/tools/ci/README b/src/tools/ci/README
index d183648a8d0..97426096f7a 100644
--- a/src/tools/ci/README
+++ b/src/tools/ci/README
@@ -61,7 +61,7 @@ Controlling CI via commit messages
The behavior of CI can be controlled by special content in commit
messages. Currently the following controls are available:
-- ci-os-only: {(freebsd|linux|macos|mingw|netbsd|openbsd|windows)}
+- ci-os-only: {(freebsd|linux|macos|mingw|netbsd|openbsd|vs2019|windows)}
Only runs CI on operating systems specified. This can be useful when
addressing portability issues affecting only a subset of platforms.
@@ -92,4 +92,4 @@ credits too quickly. This can be changed on the repository level, e.g. when
custom compute resources are configured.
The following repository level environment variables are recognized:
-- REPO_CI_AUTOMATIC_TRIGGER_TASKS - space-separated list of (mingw|netbsd|openbsd)
+- REPO_CI_AUTOMATIC_TRIGGER_TASKS - space-separated list of (mingw|netbsd|openbsd|vs2019)
--
2.51.0
On 08.09.25 10:25, Nazir Bilal Yavuz wrote:
Tasks have short names to select them and the 'Windows VS 2019' task's
name was 'windows' (i.e: ci-os-only: windows) but since we have two
Windows tasks now; we need to have different names for VS 2019 and VS
2022 tasks. To preserve the same behavior, VS 2022 task uses 'windows'
but VS 2019 is renamed to 'vs2019' (i.e: ci-os-only: vs2019). I am not
completely convinced about this naming, I am open to suggestions.
I don't think we need this level of complication. We already have the
situation that for example "linux" covers several tasks, and "windows"
also covers several tasks, one of which is manually triggered. The
"ci-os-only: vs2019" is not very useful anyway, since it's manually
triggered. So just applying "windows" to both of them seems ok to me.
On Thu, Sep 11, 2025 at 7:18 AM Peter Eisentraut <peter@eisentraut.org> wrote:
I don't think we need this level of complication. We already have the
situation that for example "linux" covers several tasks
Recently, I've wished that it were otherwise; if I'm debugging a
Meson-only test failure in Linux, I don't want to burn credits running
Autoconf.
and "windows"
also covers several tasks, one of which is manually triggered.
I think it only covers one? The other is `mingw` (and I've used that
one recently, for the pytest work).
--Jacob
Hi,
On Thu, 11 Sept 2025 at 17:55, Jacob Champion
<jacob.champion@enterprisedb.com> wrote:
On Thu, Sep 11, 2025 at 7:18 AM Peter Eisentraut <peter@eisentraut.org> wrote:
I don't think we need this level of complication. We already have the
situation that for example "linux" covers several tasksRecently, I've wished that it were otherwise; if I'm debugging a
Meson-only test failure in Linux, I don't want to burn credits running
Autoconf.
I agree with Jacob. I think it would be better if each task had its
own tag. I left it as "vs2019" for now. Also, one problem is that if
we use "windows" for both tasks; then we need to use the
"CI_TRIGGER_TYPE_WINDOWS" variable to make VS 2019 task manually
triggered. However, we should not use this variable in the VS 2022
task because it will be triggered automatically. I think this causes a
bit of confusion.
The PR [1]https://github.com/anarazel/pg-vm-images/pull/116 for 'installing both VS 2022 and VS 2019 to the Windows CI
image' is merged. VS 2019 installation is set to default installation
on the Windows CI image. VS 2022 was the default installation when the
PR was created but then we switched to VS 2019 to be able to commit
this patch any time without depending on the PR.
v3 is attached. I forgot to update the MinGW task's name in the
previous versions, it is done now.
Example CI task: https://cirrus-ci.com/build/4811555264528384
[1]: https://github.com/anarazel/pg-vm-images/pull/116
--
Regards,
Nazir Bilal Yavuz
Microsoft
Attachments:
v3-0001-ci-Fix-Windows-and-MinGW-tasks-namings.patchtext/x-patch; charset=US-ASCII; name=v3-0001-ci-Fix-Windows-and-MinGW-tasks-namings.patchDownload
From 05d9ae9ce164e7275620d03a1517912287cec1e1 Mon Sep 17 00:00:00 2001
From: Nazir Bilal Yavuz <byavuz81@gmail.com>
Date: Mon, 15 Sep 2025 11:08:39 +0300
Subject: [PATCH v3 1/2] ci: Fix Windows and MinGW tasks' namings
They use Windows Server 2022, not 2019.
Author: Nazir Bilal Yavuz <byavuz81@gmail.com>
Discussion: https://postgr.es/m/flat/CAN55FZ1OsaM+852BMQDJ+Kgfg+07knJ6dM3PjbGbtYaK4qwfqA@mail.gmail.com
---
.cirrus.tasks.yml | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/.cirrus.tasks.yml b/.cirrus.tasks.yml
index eca9d62fc22..12236569c13 100644
--- a/.cirrus.tasks.yml
+++ b/.cirrus.tasks.yml
@@ -752,7 +752,7 @@ WINDOWS_ENVIRONMENT_BASE: &WINDOWS_ENVIRONMENT_BASE
task:
- name: Windows - Server 2019, VS 2019 - Meson & ninja
+ name: Windows - Server 2022, VS 2019 - Meson & ninja
<< : *WINDOWS_ENVIRONMENT_BASE
env:
@@ -811,7 +811,7 @@ task:
task:
<< : *WINDOWS_ENVIRONMENT_BASE
- name: Windows - Server 2019, MinGW64 - Meson
+ name: Windows - Server 2022, MinGW64 - Meson
# See REPO_CI_AUTOMATIC_TRIGGER_TASKS in .cirrus.star.
trigger_type: $CI_TRIGGER_TYPE_MINGW
--
2.51.0
v3-0002-ci-windows-Default-to-VS-2022-run-VS-2019-task-ma.patchtext/x-patch; charset=US-ASCII; name=v3-0002-ci-windows-Default-to-VS-2022-run-VS-2019-task-ma.patchDownload
From 6f0f801e9e0b24682a537b78c9da4afcd25cdc41 Mon Sep 17 00:00:00 2001
From: Nazir Bilal Yavuz <byavuz81@gmail.com>
Date: Thu, 4 Sep 2025 17:20:18 +0300
Subject: [PATCH v3 2/2] ci: windows: Default to VS 2022, run VS 2019 task
manually
Both VS 2019 and VS 2022 are available on the Windows image [1], but
since VS 2022 is the latest version, make it the default. The VS 2019
task is still available but must be triggered manually.
[1] https://github.com/anarazel/pg-vm-images/pull/116
Author: Nazir Bilal Yavuz <byavuz81@gmail.com>
Discussion: https://postgr.es/m/flat/CAN55FZ1OsaM+852BMQDJ+Kgfg+07knJ6dM3PjbGbtYaK4qwfqA@mail.gmail.com
---
.cirrus.star | 3 ++-
.cirrus.tasks.yml | 14 ++++++++++++--
2 files changed, 14 insertions(+), 3 deletions(-)
diff --git a/.cirrus.star b/.cirrus.star
index e9bb672b959..cecd9bb026c 100644
--- a/.cirrus.star
+++ b/.cirrus.star
@@ -73,7 +73,7 @@ def compute_environment_vars():
# REPO_CI_AUTOMATIC_TRIGGER_TASKS="task_name other_task" under "Repository
# Settings" on Cirrus CI's website.
- default_manual_trigger_tasks = ['mingw', 'netbsd', 'openbsd']
+ default_manual_trigger_tasks = ['mingw', 'netbsd', 'openbsd', 'vs2019']
repo_ci_automatic_trigger_tasks = env.get('REPO_CI_AUTOMATIC_TRIGGER_TASKS', '')
for task in default_manual_trigger_tasks:
@@ -103,6 +103,7 @@ def compute_environment_vars():
'netbsd',
'openbsd',
'sanitycheck',
+ 'vs2019',
'windows',
]
commit_message = env.get('CIRRUS_CHANGE_MESSAGE')
diff --git a/.cirrus.tasks.yml b/.cirrus.tasks.yml
index 12236569c13..1c947874ae2 100644
--- a/.cirrus.tasks.yml
+++ b/.cirrus.tasks.yml
@@ -752,7 +752,6 @@ WINDOWS_ENVIRONMENT_BASE: &WINDOWS_ENVIRONMENT_BASE
task:
- name: Windows - Server 2022, VS 2019 - Meson & ninja
<< : *WINDOWS_ENVIRONMENT_BASE
env:
@@ -775,10 +774,21 @@ task:
-Dplperl=enabled
-Dplpython=enabled
+ matrix:
+ - name: Windows - Server 2022, VS 2022 - Meson & ninja
+ env:
+ # Use VS 2022
+ PATH: C:\VS_2022\VC\Auxiliary\Build;${PATH}
+ only_if: $CI_WINDOWS_ENABLED
+
+ # VS 2019 is the default VS installation
+ - name: Windows - Server 2022, VS 2019 - Meson & ninja
+ trigger_type: $CI_TRIGGER_TYPE_VS2019
+ only_if: $CI_VS2019_ENABLED
+
<<: *windows_task_template
depends_on: SanityCheck
- only_if: $CI_WINDOWS_ENABLED
setup_additional_packages_script: |
REM choco install -y --no-progress ...
--
2.51.0
Hi,
On 2025-09-15 11:50:07 +0300, Nazir Bilal Yavuz wrote:
On Thu, 11 Sept 2025 at 17:55, Jacob Champion
<jacob.champion@enterprisedb.com> wrote:On Thu, Sep 11, 2025 at 7:18 AM Peter Eisentraut <peter@eisentraut.org> wrote:
I don't think we need this level of complication. We already have the
situation that for example "linux" covers several tasksRecently, I've wished that it were otherwise; if I'm debugging a
Meson-only test failure in Linux, I don't want to burn credits running
Autoconf.I agree with Jacob. I think it would be better if each task had its
own tag. I left it as "vs2019" for now.
I don't really agree that this is something that needs to be changed as part
of this. Or that the CI_OS_ONLY is really the way to tackle this.
Perhaps we should just have CI_TASK_ONLY and CI_OS_ONLY?
Greetings,
Andres Freund
Hi,
On Thu, 18 Sept 2025 at 15:30, Andres Freund <andres@anarazel.de> wrote:
Hi,
On 2025-09-15 11:50:07 +0300, Nazir Bilal Yavuz wrote:
On Thu, 11 Sept 2025 at 17:55, Jacob Champion
<jacob.champion@enterprisedb.com> wrote:On Thu, Sep 11, 2025 at 7:18 AM Peter Eisentraut <peter@eisentraut.org> wrote:
I don't think we need this level of complication. We already have the
situation that for example "linux" covers several tasksRecently, I've wished that it were otherwise; if I'm debugging a
Meson-only test failure in Linux, I don't want to burn credits running
Autoconf.I agree with Jacob. I think it would be better if each task had its
own tag. I left it as "vs2019" for now.I don't really agree that this is something that needs to be changed as part
of this.
Definitely.
Or that the CI_OS_ONLY is really the way to tackle this.
Perhaps we should just have CI_TASK_ONLY and CI_OS_ONLY?
I think this is a good idea. How about something like the attached? It
allows you to expand to the CI_*_ONLY option.
--
Regards,
Nazir Bilal Yavuz
Microsoft
Attachments:
ci-Add-CI_TASK_ONLY.patchtext/x-patch; charset=US-ASCII; name=ci-Add-CI_TASK_ONLY.patchDownload
From 7a1f1df4345cdd401062adc046b74bc275f0b31a Mon Sep 17 00:00:00 2001
From: Nazir Bilal Yavuz <byavuz81@gmail.com>
Date: Fri, 19 Sep 2025 14:32:29 +0300
Subject: [PATCH v1] ci: Add CI_TASK_ONLY
Expand CI_OS_ONLY with CI_TASK_ONLY. This allows to differentiate OSes
from the tasks.
---
.cirrus.star | 111 +++++++++++++++++++++++++++++++++-------------
.cirrus.tasks.yml | 2 +-
2 files changed, 80 insertions(+), 33 deletions(-)
diff --git a/.cirrus.star b/.cirrus.star
index e9bb672b959..f718befa9c6 100644
--- a/.cirrus.star
+++ b/.cirrus.star
@@ -63,10 +63,9 @@ def main():
return output
-def compute_environment_vars():
+def compute_automatic_trigger_tasks():
cenv = {}
- ###
# Some tasks are manually triggered by default because they might use too
# many resources for users of free Cirrus credits, but they can be
# triggered automatically by naming them in an environment variable e.g.
@@ -83,42 +82,90 @@ def compute_environment_vars():
else:
value = 'manual'
cenv[name] = value
- ###
- ###
- # Parse "ci-os-only:" tag in commit message and set
- # CI_{$OS}_ENABLED variable for each OS
+ return cenv
- # We want to disable SanityCheck if testing just a specific OS. This
- # shortens push-wait-for-ci cycle time a bit when debugging operating
- # system specific failures. Just treating it as an OS in that case
+
+def compute_ci_regex_helper(name):
+ return r"(^|.*\n)ci-{}-only: ([^\n]+)($|\n.*)".format(name)
+
+def compute_ci_tasks(compute_ci_dict):
+ cenv = {}
+
+ # Parse "ci-{name}-only:" tag in commit message and set
+ # CI_${NAME}_ENABLED variable for each OS or task
+
+ # We want to disable SanityCheck if testing just a specific OS or task.
+ # This shortens push-wait-for-ci cycle time a bit when debugging operating
+ # system specific failures. Just treating it as an OS or task in that case
# suffices.
-
- operating_systems = [
- 'compilerwarnings',
- 'freebsd',
- 'linux',
- 'macos',
- 'mingw',
- 'netbsd',
- 'openbsd',
- 'sanitycheck',
- 'windows',
- ]
commit_message = env.get('CIRRUS_CHANGE_MESSAGE')
- match_re = r"(^|.*\n)ci-os-only: ([^\n]+)($|\n.*)"
- # re.match() returns an array with a tuple of (matched-string, match_1, ...)
- m = re.match(match_re, commit_message)
- if m and len(m) > 0:
- os_only = m[0][2]
- os_only_list = re.split(r'[, ]+', os_only)
- else:
- os_only_list = operating_systems
+ # Firstly, try to find if there is specification. If yes, then it is safe
+ # to disable not specified tasks.
+ specified = False
+ for name in compute_ci_dict:
+ match_re = compute_ci_regex_helper(name)
+ # re.match() returns an array with a tuple of (matched-string, match_1, ...)
+ m = re.match(match_re, commit_message)
+ if m and len(m) > 0:
+ # We have at least one specified task
+ specified = True
+ break
- for os in operating_systems:
- os_enabled = os in os_only_list
- cenv['CI_{0}_ENABLED'.format(os.upper())] = os_enabled
+ for name in compute_ci_dict:
+ name_list = compute_ci_dict[name]
+
+ # Same as above
+ match_re = compute_ci_regex_helper(name)
+ m = re.match(match_re, commit_message)
+
+ name_only_list = []
+ if m and len(m) > 0:
+ name_only = m[0][2]
+ name_only_list = re.split(r'[, ]+', name_only)
+ elif not specified:
+ name_only_list = name_list
+
+ for name in name_list:
+ name_enabled = name in name_only_list
+ cenv['CI_{0}_ENABLED'.format(name.upper())] = name_enabled
+
+ return cenv
+
+
+def compute_environment_vars():
+ cenv = {}
+ cenv.update(compute_automatic_trigger_tasks())
+
+ ###
+ # Compute which tasks to run
+ compute_ci_dict = {}
+
+ operating_systems = {
+ 'os':
+ [
+ 'freebsd',
+ 'linux',
+ 'macos',
+ 'netbsd',
+ 'openbsd',
+ 'windows',
+ ]
+ }
+ compute_ci_dict.update(operating_systems)
+
+ tasks = {
+ 'task':
+ [
+ 'compilerwarnings',
+ 'mingw',
+ 'sanitycheck',
+ ]
+ }
+ compute_ci_dict.update(tasks)
+
+ cenv.update(compute_ci_tasks(compute_ci_dict))
###
return cenv
diff --git a/.cirrus.tasks.yml b/.cirrus.tasks.yml
index eca9d62fc22..e655a95b45a 100644
--- a/.cirrus.tasks.yml
+++ b/.cirrus.tasks.yml
@@ -817,7 +817,7 @@ task:
trigger_type: $CI_TRIGGER_TYPE_MINGW
depends_on: SanityCheck
- only_if: $CI_MINGW_ENABLED
+ only_if: $CI_MINGW_ENABLED || $CI_WINDOWS_ENABLED
env:
TEST_JOBS: 4 # higher concurrency causes occasional failures
--
2.51.0
On 2025-09-15 11:50:07 +0300, Nazir Bilal Yavuz wrote:
v3 is attached. I forgot to update the MinGW task's name in the
previous versions, it is done now.
I pushed the s/2019/2022/ portion now.
I'm still not convinced by the OS enablement for vs*...
Greetings,
Andres
Hi,
On Thu, 30 Oct 2025 at 20:26, Andres Freund <andres@anarazel.de> wrote:
On 2025-09-15 11:50:07 +0300, Nazir Bilal Yavuz wrote:
v3 is attached. I forgot to update the MinGW task's name in the
previous versions, it is done now.I pushed the s/2019/2022/ portion now.
Thanks!
I'm still not convinced by the OS enablement for vs*...
What do you think about introducing CI_TASK_ONLY like in the [1]/messages/by-id/CAN55FZ2d4Qa=ZXpuDxnoUn28G+Z0e06LwWS1qpZ-UNRAsWY2VQ@mail.gmail.com?
[1]: /messages/by-id/CAN55FZ2d4Qa=ZXpuDxnoUn28G+Z0e06LwWS1qpZ-UNRAsWY2VQ@mail.gmail.com
--
Regards,
Nazir Bilal Yavuz
Microsoft