search

StefanScherer / packer-windows

Windows Templates for Packer: Windows 11, Windows 10, Windows Server 2022, 2019, 2016, also with Docker
MIT License
1.29k stars 434 forks source link

Windows 10: Add VirtualBox, KVM CI #270

Open qmfrederik opened 4 years ago

qmfrederik commented 4 years ago

This PR adds CI for the Windows 10 packer image for the VirtualBox and KVM builders.

Other environments should be easy to add; if you decide to enable CI in this repo, I can send up a follow up PR for Windows Server and Windows 7 or 8.1

StefanScherer commented 4 years ago

Oh that's really interesting that you can run packer on just some CI machines 👍

I'm not sure if I want to actually build images here. My use-case is for VMware, and I use a different repo packer-builder for that from time to time. It costs a bit of money as I use baremetal machines on demand.

qmfrederik commented 3 years ago

So, as a sidenote, #281 and #282 have regressed/broken building QEMU images.

They reacted to a recent change in packer, where specifying -drive arguments in qemuargs would replace the default drives generated by Packer, rather than adding new drives. (I think this was caused by packer-plugin-qemu/commit/4a5c5ce817795d1d1134fdb6fbf7f988088e0ef9, but not sure).

However, the fix used was to specify:

        [
          "-drive",
          "file={{ user `iso_url` }},media=cdrom,index=2"
        ],

which would mount an ISO file over HTTP. This is probably not a good idea, and the remote server does not support it. It causes the Packer build to fail like this:

qemu-system-x86_64: -drive file=https://software-download.microsoft.com/download/sg/19043.928.210409-1212.21h1_release_svc_refresh_CLIENTENTERPRISEEVAL_OEMRET_x64FRE_en-us.iso,media=cdrom,index=2: CURL: Error opening file: Server does not support 'range' (byte ranges).

For now, I worked around this by reverting those changes and using an older Packer version (1.6.0).

I guess it demonstrates that having CI to validate changes to the .json files may be useful :-).

StefanScherer commented 3 years ago

Hey @qmfrederik Thanks again for your PR. ❤️ Yes, I agree that having CI gives feedback and helps avoiding regression. But on the other side as a maintainer who doesn't use QEMU at all I'm hesitant of adding more and more things to this repo. That's the hard decision to say "no" to some things, just to avoid future maintenance cost/time. And even waiting for CI results or fixing some minor things are additional time that "costs" something.

The CI can also be activated in forks. So what I could think of is to merge your PR to have the yml files in the repo, and also follow up PR's to fix KVM/QEMU configuration sections. But I'm not planning to activate the additional CI in this repo here, because I wouldn't take care of it/wait for it when I merge PRs for other things.

I understand this is a difficult topic when PRs don't get merged easily. I already accepted the first KVM/QEMU PR's to be kind, now I have to live with follow up fixes. I'm trying to find a way that keeps me out of the loop for such other builders.

What do you think? Would that work for you if you run the CI in your fork?

manics commented 3 years ago

I've had similar issues with complicated CI workflows in other repos. One idea I've had is to create a repo just for the extra CI workflows, e.g. packer-windows-ci-qemu:

I haven't actually tried this yet, but I think it'd be easier than manually maintaining a fork since dependabot will do most of the work.

rautends commented 1 year ago

What do you think? Would that work for you if you run the CI in your fork?

@StefanScherer i don't think that's the right way because it limits the growth of the project. simply allow to maintain @qmfrederik the repo / pipelines, if you/he is still interested in. so the development can driven by two persons.