potatoqualitee / psmodulecache

This action makes caching PowerShell modules from the PowerShell Gallery easy for Linux, Windows and macOS runners.
MIT License
31 stars 12 forks source link

About the next version 6.0 #55

Closed LaurentDardenne closed 1 year ago

LaurentDardenne commented 1 year ago

After several months of testing and building scenarios (there are still some left) I will soon deliver a version which corrects some defects of the last version.

Changes :

Breaking changes

Known issues

    - name: Known issue
      uses: potatoqualitee/psmodulecache@v6.0
      with:
        modules-to-cache: Pester:5.3.0
        modules-to-cache-prerelease: Pester:5.3.0-beta1

In this case we consider and record both versions but it is the prerelease version which will be saved last in the ".\Pester\5.3.0" directory.

The following setting can also produce the same effect (we assume that at least one stable version exists and that its version number is lower than 2.0.0):

    - name: Known issue
      uses: potatoqualitee/psmodulecache@v6.0
      with:
        modules-to-cache: "WipModule::"
        modules-to-cache-prerelease: WipModule:2.0.0-beta

The problem will occur as soon as version 2.0.0 is released.

If we authorize the configuration with the same module of different version but coming from two repositories:

    - name: Known issue
      uses: potatoqualitee/psmodulecache@v6.0
      with:
        modules-to-cache: ProdStableRepository\MyModule:1.0.0
        modules-to-cache-prerelease: "DevPrereleaseRepository\MyModule::"

we implicitly authorize the following case:

    - name: Known issue
      uses: potatoqualitee/psmodulecache@v6.0
      with:
        modules-to-cache: PSModuleCache\Duplicate,PSGallery\string

Here we register two versions of the 'String' module but each package has a different module GUID. We let the user check the consistency of what they configure.

Note : Under Powershell Core this last setting works some times and other times causes an error (caused by PSmoduleCache) ...