This is a followup of https://github.com/containers/podman/pull/26048
It fixes `process-release.ps1` that was always looking for the amd64 release
zip file, even if `$env:PODMAN_ARCH` was set to arm64. With this fix it looks
for the right zip file.
It fixes `winmake.ps1` that, when the `-arch` param was not passed, set `$env:PODMAN_ARCH`
to the empty string instead of the local `$env:GOARCH`.
Signed-off-by: Mario Loriedo <mario.loriedo@gmail.com>
Winmake could only build amd64 artifacts (podman-remote, gvproxy,
win-sshproxy, podman.msi and podman-setup.exe).
This commit makes the necessary change to winmake so that it:
1) builds arm64 artifacts when executed on arm64
2) cross-compiles to arm64/amd64 with the `-architecture` parameter
It depends on https://github.com/containers/podman/pull/26023 that
removes the need to build `check.c` code (that is not used anyway).
Signed-off-by: Mario Loriedo <mario.loriedo@gmail.com>
The Windows installer was able to automatically enable the
Windows features for WSL or HyperV when they were not
already enabled. This PR removes this capability.
Having the installer to automatically install the right prerequiste
(WSL or HyperV) was helpful as users won't have to do it manually to
use Podman after the installation. But it also made the code of
installer more complicated as it needed to manage the installation
of these OS features and a reboot. And we weren't able to automatically
test these scenarios that required a reboot.
In other words the Windows installer, that merely just extracted
some files in a folder, required, to support the installation of
WSL and HyperV, an advanced knowledge of WiX toolkit and of the
Windows Installer SDK, plus contributors-time to manually test
the scenarios that require a reboot.
We decided to remove this capability based on the following reasons:
- We had a couple of regressions in the last month that were hard to
analyse and fix (#24624 and #24735)
- Podman maintainers currently have a scarce knowledge of the Windows Installer
and there is no plan to invest in that
- Manually installing WSL or HyperV is not hard (e.g. run `wsl --install`) and
are features that admins can manage on their fleet of Windows machines
- Competitors such as Docker Desktop don't automatically install these
components
- Podman `machine init` currently verifies if WSL and HyperV are installed and
guide the user to install them when they are not
Signed-off-by: Mario Loriedo <mario.loriedo@gmail.com>
Added a condition in the Windows WiX bundle that
prevents upgrades from v5.3.1 and recommend the
user to upgrade to v5.3.2 first.
That's needed because version 5.3.1 of the installer
had a bug that got patched in v5.3.2 only.
c.f. https://github.com/containers/podman/issues/24735
Signed-off-by: Mario Loriedo <mario.loriedo@gmail.com>
For some reason, after upgrading to WiX v5, the forceReboot action
appeared before the Dism actions in the msi InstallExecuteSequence
table. As a consequence the user was asked to reboot before WSL or
Hyper-V installation and to reboot a second time after their
installation.
To avoid that the ForceReboot action field `Before=StopServices` is
replaced with `After=DismX86`
Signed-off-by: Mario Loriedo <mario.loriedo@gmail.com>
When building an installer from main branch, and using it
to upgrade the latest Podman release on Windows, a reboot
is triggered if WSL is not installed.
This is a regression caused by an update of the condition
to execute `ForceReboot`.
This commit fixes the condition and updates some defaults
to make it even more unlikely that reboot happens withtout
a specific user request for it.
It doesn't fix the v5.3.1 to v5.3.2 upgrade though. v5.3.1
has been released already and this commit doesn't avoid that it
triggers a reboot when updated.
Signed-off-by: Mario Loriedo <mario.loriedo@gmail.com>
Adding a patch to the bundle so that the update from previous version
(v5.3.1) is a minor update, not a major one. A minor update prevents the
full uninstallation of v5.3.1 and an unrequested reboot of the machine.
Signed-off-by: Mario Loriedo <mario.loriedo@gmail.com>
When one or more versions of VS Build tools are installed the script
.\winmake.ps1 installer does not finish with error.
...
Done!
Invoke-Expression: C:\...\podman\contrib\cirrus\win-lib.ps1:101:5
Line |
101 | Invoke-Expression $command -OutVariable unformattedLog | Write-Output
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| Cannot process argument transformation on parameter 'vsinstance'. Cannot convert the "System.Object[]" value of type "System.Object[]" to type
| "Microsoft.VisualStudio.Setup.Instance".
Signed-off-by: Nicola Sella <nsella@redhat.com>
Do not pull from a moving target, use a defined version so updates must
happen in a PR and do not break others.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
The windows installer tests are command line / non interactive. To test as much as
possible the GUI / interactive scenario (that is what user do), update tests
need to use the installer with the default options. That's because when using the GUI
for an update, changing options is not possible.
Signed-off-by: Mario Loriedo <mario.loriedo@gmail.com>
The condition `NOT Installed` had not effect and has been replaced with
`NOT WIX_UPGRADE_DETECTED` that is `true` during installation and
`false` during updates.
The `ExePackage` WSL Kernel Install is also not installed if Podman is
already present.
Signed-off-by: Mario Loriedo <mario.loriedo@gmail.com>
The Windows installer GUI has a checkbox to choose if WSL and HyperV
should be installed as part of the installation of Podman. Now, by
default, that checkbox is disabled for both WSL and HyperV.
Signed-off-by: Mario Loriedo <mario.loriedo@gmail.com>
Use Schedule "afterInstallExecute" (instead of the
default "afterInstallValidate") in the Windows
installer MajorUpgrade element. That avoid
overriding eventual users changes to the podman
machine configuration file created by the
installer.
Fixes#23502
Signed-off-by: Mario Loriedo <mario.loriedo@gmail.com>
Building the MSI hook on Windows
(`contrib/win-installer/podman-msihooks/check.c`)
currently requires MinGW. This commit updates the build
script so that, when MinGW is absent but the C compiler
included in Visual Studio BuildTools is installed, the
latter is used to build the MSI hook.
Other than that, `winmake.ps1` has a new `installertest`
target to run the Windows installer tests that are
currently verified by Cirrus CI.
Signed-off-by: Mario Loriedo <mario.loriedo@gmail.com>
The chocolatey tool that was fetching us wix v3 can no longer be used to
fetch wix v4+ so we had to switch to dotnet to fetch the latest wix.
This commit builds the installer with wix v5.
wix v5 is installed via the `dotnet` tool in the windows image itself
at https://github.com/containers/automation_images/pull/354.
Going forward, the `dotnet` tool will also be used to build the installer.
In the process, the wix v3 files were converted to wix v4+ using `wix
convert` followed by manual modifications along with switch to wixproj
builds with dotnet.
The GitHub Action to upload windows installer now builds the installer
using winmake.ps1.
Contributions from Mario Loriedo:
- bundle setup update to wix5
- updates to build and release process scripts
Ref: https://github.com/lsm5/podman/pull/3
- small fixes to windows installer theme
Ref: https://github.com/lsm5/podman/pull/4
- Better win-installer sidebar logo
Ref: https://github.com/lsm5/podman/pull/5
Resolves: RUN-2055
Co-authored-by: Mario Loriedo <mario.loriedo@gmail.com>
Signed-off-by: Lokesh Mandvekar <lsm5@redhat.com>
podman.msi GUI has a radio-button to select WSL or Hyper-V
The checkbox in podman.msi GUI allow the user to specify if
the machine provider installation (WSL or Hyper-V) should
be part of podman installation or not.
podman-setup.exe supports 2 new variables: MachineProvider
(valid values are `wsl` and `hyperv`) and HyperVCheckbox
(valid values are `0` and `1`)
Installation creates the configuration file
`99-podman-machine-provider.conf` under folder
`%APPDATA\containers\containers.conf.d` with the selected
machine provider
Cirrus CI `win_installer_task` tests the installation with
both `hyperv` and `wsl` and verifies the configuration.
Uninstallation is tested too.
Note that podman-setup.exe GUI doesn't allow to choose the
provider yet. See https://github.com/containers/podman/issues/22492
Signed-off-by: Mario Loriedo <mario.loriedo@gmail.com>
we are having second thoughts about *requiring* a policy.json on podman
machine hosts. we are concerned that we need to work out some more use
cases to be sure we do not make choices now that limit us in the near
term future. for example, should the policy files be the same for
container images and machine images? And should one live on the host
machine and the other live in the machine?
therefore, if a policy.json *is* present in the correct location, we will use and honor it; however, if it does not, we will allow the machine image to be pulled without a policy.
Signed-off-by: Brent Baude <baude@redhat.com>
Co-authored-by: Paul Holzinger <45212748+Luap99@users.noreply.github.com>
Signed-off-by: Brent Baude <bbaude@redhat.com>
- Sets default search location to always be the peer directory
+ make podman-remote now creates binaries that work the same as release zips
- Updates release zip to match expected search location
- Updates win installer to include the file if present in the repo cross-build
archive
[NO NEW TESTS NEEDED]
Signed-off-by: Jason T. Greene <jason.greene@redhat.com>
Updated build scripts and installer build scripts to include gvproxy.exe.
Includes tutorial on setting up a Podman VM with QEMU and gvproxy on Windows.
Signed-off-by: Arthur Sengileyev <arthur.sengileyev@gmail.com>
Also reuse install location for previous installs if present
Example Usage: .\podman-4.3.2-setup.exe InstallFolder=C:\Other\Loc
Signed-off-by: Jason T. Greene <jason.greene@redhat.com>
