Should modules update automatically?

[aaronparker]

Force is set to $True by default, but modules aren't updating automatically. Should the action update to the latest version of a module automatically or am I expecting a behaviour that's not as intended?

I use the action in a few workflows (e.g. update-json.yml); however, unless I specify a module version, the modules don't update to newer versions of a module.

[potatoqualitee]

You are expecting a behavior that is not intended, but could be a very cool feature. I'll see what I can do 👍🏼

[aaronparker]

Thanks for the quick reply. I've started using psmodulecache in my workflows, because I think it's more elegant than using a script. I am using the action in a few workflows that uses a specific module that updates often, hence looking to get modules to update.

In the meantime, I've added Update-Module to my workflows.

[LaurentDardenne]

I also have this need for the following scenario: Before uploading my modifications I use a local build on my computer, this build is reused in a remote CI. In this case, if you don't specify a version when installing the necessary modules, you can have different versions locally and in the VM. The build can therefore fail following breaking changes in the modules, in these cases I used a semi-automatic update locally. Since the CI always uses the latest version. (this way of doing things is also useful to me if I work in an environment without internet access).

If I use this scenario with PSModuleCache, I will encounter the same problem.

A possible solution: 1- Add a boolean 'Updatable' parameter to the Action. The value 'True' indicates to check for updates for the requested modules. We add in the cache key the cache type, here 'Updatable' (can be useful in Github CLI). The value 'False' does not trigger any updates of the requested modules. We add in the cache key the cache type, here 'Immutable'.

2 - Enrich the syntax of the 'modules-to-cache' parameter in order to allow: -to use a fixed version (required), which already exists, -to use a module without specifying its version or its update (regardless of the version [the one in the cache or in the repository]), which already exists, -to use a module by specifying its update (always use the latest version), which does not exist. The workflow does not need to know the version number, but to know for which modules it forces an update at each execution. For the latter case, the '::' pattern can be used without indicating a version number. Its presence indicates the triggering of a search for a new version and the creation of a new cache key if necessary. (To date there is no naming convention for module names, so you can find any character there except those prohibited by the targeted FileSystem. Here it does not interfere because you create a key name not a file name)

Key examples : For : module-to-cache='PSFramework,Pester,dbatools:1.1.0,DTW.PS.FileSystem' Updateble=false The key is 'Windows-v4.5-Immutable-powershell-pwsh-PSFramework-Pester-dbatools:1.1.0--DTW.PS.FileSystem'

For : module-to-cache='PSFramework,Pester::,dbatools:1.1.0,DTW.PS.FileSystem' Updateable=true The key is 'Windows-v4.5-Updatable-powershell-pwsh-PSFramework-Pester:5.3.3-dbatools:1.1.0-DTW.PS.FileSystem'

Note that 'allow-prerelease' will influence the version fetched. Example https://www.powershellgallery.com/packages/PnP.PowerShell/1.11.0 For this module we get a new version every day.

We must add consistency checks:

This also includes managing multiple repositories :

[LaurentDardenne]

Example of a result:

[potatoqualitee]

This issue has been resolved 😊 thank you again Laurent!