Обсуждение: 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] 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. 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
Вложения
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], 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]: https://www.postgresql.org/message-id/flat/01a69441-af54-4822-891b-ca28e05b215a%40eisentraut.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: https://www.postgresql.org/message-id/flat/CADK3HHL9hJnCxttPnhPvdNdXC_7ger%3DiarMMy0KOrOOweaMAxw%40mail.gmail.com#75363fb1078b930736ad7fc7b9f95910 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] 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] 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] 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
Вложения
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
Вложения
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 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. 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] 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
Вложения
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 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. > > 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 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. > > > > 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