win_psmodule error: A parameter cannot be found that matches parameter name 'AcceptLicense' in 1.11.0

[shadowink]

SUMMARY

In 1.11.0 win_psmodule is throwing the error:Problems installing PSSlack module: A parameter cannot be found that matches parameter name 'AcceptLicense'.

ISSUE TYPE

• Bug Report

COMPONENT NAME

win_psmodule

ANSIBLE VERSION

2.11.6

COLLECTION VERSION

1.11.0

CONFIGURATION

OS / ENVIRONMENT

Ansible running on a Win10 20h2 VM via a packer build.

STEPS TO REPRODUCE

- name: Add Powershell Slack module
  community.windows.win_psmodule:
    name: PSSlack
    state: present

EXPECTED RESULTS

{
"changed": true,
"nuget_changed": true,
"output": "Module PSSlack installed",
"repository_changed": false
}

ACTUAL RESULTS

"msg": "Problems installing PSSlack module: A parameter cannot be found that matches parameter name 'AcceptLicense'."

I downgrading the collection to 1.10.0 and the error did not occur.

[jborean93]

What's the version of Get-Module -Name PowerShellGet -ListAvailable on the host in question? There is a minimum version requirement https://docs.ansible.com/ansible/latest/collections/community/windows/win_psmodule_module.html#notes of 1.6.0 which should be new enough to include the -AcceptLicense parameter.

cc @briantist considering how crappy the UX is to upgrade PowerShellGet and PackageManagement through PowerShell and that we are meant to run on Windows PowerShell out of the box, is it possible to put the license feature behind a feature check?

[briantist]

re: feature check: I suppose we could do something like (Get-Command Install-Module).Parameters.ContainsKey('AcceptLicense') to check.

I suspect that the issue is that I perhaps incorrectly added the parameter to the internal function that installs the pre-requisites:
https://github.com/ansible-collections/community.windows/blob/main/plugins/modules/win_psmodule.ps1#L95

So probably on this fresh host, it's trying to get the required modules to their minimums and hitting the problem there. Since those modules will never need the license check, we can probably just remove this line instead of feature testing.

Ideally we'd have a test for this pre-req functionality but I'm not sure how much of a pain that will be to implement in CI, given that all the other tests install the minimum versions as a setup step. The test could only successfully run against a CI host that didn't run any of the other PowerShellGet tests I guess.

[jborean93]

Ah I forgot we update the pre-req if needed so yea sounds like the bootstrapping needs a better check to ensure it doesn't add -AcceptLicence in that case. As for testing it's going to be difficult, the reason we install the pre-reqs beforehand is to avoid internet requirements and make the tests more stable. It would be nice to test out the pre-req updater code in the module which might even work if we set up the local repository to contain the required PackageManagement and PowerShellGet nupkgs and don't update it outside the tests.

[briantist]

Right, I suppose it could work as long as the default repository is removed from the system during the tests (I think it is). But to my mind the bigger issue is that the setup for other tests will not remove the newer versions of the packages, so if they run first, this test won't be testing against a system with the OOB versions.

Or do you mean that we replace setup_win_psget completely, and use win_psmodule to install pre-reqs (albeit with a local repository as the source), thus sort of implicitly testing the pre-req functionality in the course of doing setup for other tests?

[jborean93]

We can always just have a final task in the win_psmodule tests to remove the newly added PowerShellGet and PackageManagement folders. That way

• setup_win_psget does the nuget.dll, and downloads the nupkg for the new min PowerShellGet and PackageManagement to a local dir
• win_psmodule will set up the repos properly so only the local filesystem (which the above nupkgs are in) will be used
• The first task will update the nupkg which should be asserted in the test
• The end will remove the newly installed versions
• Other tests will just use whatever is out of the box which should stay as the old versions (unless they themselves need a new one)

Hopefully that makes sense.

[briantist]

I think it mostly makes sense, except the part about using OOB versions, since as far as I know none of the psget stuff we have uses those (all the tests use the setup, since we require the same minimums for everything), though maybe I'm misremembering.

[jborean93]

The PR #425 should fix this. It ensures the bootstrapping code in win_psmodule is used to update the test PowerShellGet and PackageManagement allowing us to pick up this type of problem in the future.

[kiweezi]

Hey @jborean93,

Thanks for fixing this! I've just been having trouble with it this afternoon.
How should I upgrade my local collection to include this change? I can see the releases are a manual process.
Or should I install 1.10.0 instead?

[briantist]

@kiweezi until the change is included in a release, you may opt to install the collection from git. I believe the command would be:

ansible-galaxy collection install git+https://github.com/ansible-collections/community.windows.git,main

Going back to 1.10.0 is also an option.

[kiweezi]

@kiweezi until the change is included in a release, you may opt to install the collection from git. I believe the command would be:

ansible-galaxy collection install git+https://github.com/ansible-collections/community.windows.git,main

Going back to 1.10.0 is also an option.

Ah I didn't realise you could do that, I've just tried it and things are working. Thanks a bunch!