Open jongisli opened 6 years ago
+1
+1 from me too
+1
If the one use case that is listed here is the only one, this is not a good feature as it will be abused. If there are other use cases, we would very much like to hear about them.
The use case of concern is described as: "I'm using a CI/CD process and would like to test the modules..." You should not publish to the PowerShell Gallery something you are testing, you should only publish items that are in at least a preview release state. This is a free public repo, and if everyone starts routing their release pipeline tests to the PSGallery we bear the cost of that testing, and the users of the PSGallery have to guess what has not been tested. Testing your CI/CD pipeline should be done to an internal private repo, then route to PSgallery for release.
I’m not publishing at all to the public Gallery. If this can be abused in the Gallery, my opinion is that the Gallery needs hardening.
We are indeed using private repos as you suggest. We have two NuGet repositories. One for snapshots and another for releases - we want to be able to overwrite the snapshots.
This is very standard workflow in software development. And it’s strange to hardcode a security feature like this is the package manager instead of letting the users control this in the artifact management system (e.g. Nexus/Artifactory).
Jon
On Fri, 6 Jul 2018 at 20.33, J. Keith Bankston [MSFT] < notifications@github.com> wrote:
If the one use case that is listed here is the only one, this is not a good feature as it will be abused. If there are other use cases, we would very much like to hear about them.
The use case of concern is described as: "I'm using a CI/CD process and would like to test the modules..." You should not publish to the PowerShell Gallery something you are testing, you should only publish items that are in at least a preview release state. This is a free public repo, and if everyone starts routing their release pipeline tests to the PSGallery we bear the cost of that testing, and the users of the PSGallery have to guess what has not been tested. Testing your CI/CD pipeline should be done to an internal private repo, then route to PSgallery for release.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/PowerShell/PowerShellGet/issues/200#issuecomment-403113920, or mute the thread https://github.com/notifications/unsubscribe-auth/AANqMV_3Q1cInhscNsq5uVzK8lFYsasUks5uD61sgaJpZM4QrmzV .
@jongisli That's why I asked about the use case. There are other situations where we support a capability in general but not for PSGallery. We have hardened the PSGallery by not allowing the capability. However, if the ask is to support this for repos other than the PSGallery, that's something we can consider.
“However, if the ask is to support this for repos other than the PSGallery, that's something we can consider.”
That’s exactly the request :-)
Jon
On Fri, 6 Jul 2018 at 21.00, J. Keith Bankston [MSFT] < notifications@github.com> wrote:
@jongisli https://github.com/jongisli That's why I asked about the use case. There are other situations where we support a capability in general but not for PSGallery. We have hardened the PSGallery by not allowing the capability. However, if the ask is to support this for repos other than the PSGallery, that's something we can consider.
— You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/PowerShell/PowerShellGet/issues/200#issuecomment-403119995, or mute the thread https://github.com/notifications/unsubscribe-auth/AANqMaZN0J80ErjC0swES6OfbZPZKIzHks5uD7O2gaJpZM4QrmzV .
Yes, repos other than PSGallery is the case. I found a workaround. I’m checking with Find-Module if the Module and the specific version exist and if yes then using nuget.exe to delete the existing Module from repo then reuploading the tested version again. I can cooy-paste the code if someone is interested.
We have workarounds. I made the issue on github because I felt it should be implemented this way in Publish-Module, not requiring any workarounds.
Jon
On Fri, 6 Jul 2018 at 21.31, schwaizi notifications@github.com wrote:
Yes, repos other than PSGallery is the case. I found a workaround. I’m checking with Find-Module if the Module and the specific version exist and if yes then using nuget.exe to delete the existing Module from repo then reuploading the tested version again. I can cooy-paste the code if someone is interested.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/PowerShell/PowerShellGet/issues/200#issuecomment-403126673, or mute the thread https://github.com/notifications/unsubscribe-auth/AANqMTVee0jFDLEG4sTKAx5hG6Z20PNzks5uD7sfgaJpZM4QrmzV .
+1
+1
+1
👍
Expected Behavior
Overwriting modules should be possible - without bumping version number.
Current Behavior
I'm developing PowerShell modules, and I have two nuget repositories, one for snapshots (modules under development) and another one for releases (production ready modules). I'm using Artifactory as an artifact management system, and I've set up both repositories as nuget feeds in there.
First time I publish a module with PowerShellGet, it works. If I run the Publish-Module command again right after, it fails because it won't allow me to overwrite (the user psmodulewriter has permission to overwrite):
Possible Solution
A possible solution would be to use the -Force parameter in line 1257 on the master branch in PowerShellGet/PSModule.psm1 like so:
Context
I'm using a CI/CD process and would like to test the modules I'm developing through the pipeline often, without bumping the version number every time.
This is possible using nuget. If I download the .nupkg from Artifactory and push it with nuget, it overwrites the file without any problem:
Your Environment