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
