Check for package version on choco push

[tirolo]

I would like to suggest that choco push should check the version of the package I'm trying to push against the (if available) package on the --source and give me some options on what I want to do if the package is (for instance) older, same or newer version (from my local package perspective).

So that enabling options like: --push-only-if-newer which would be quite handy.

[ferventcoder]

So what I think this would be is more of a warning. You push it and it will warn you but push anyways. Many folks use automation to push newer versions. If it stops pushing, that would be a breaking change.

[tirolo]

Can we go for something where the default action is the warning message and push the package but if the --push-only-if-newer is specified then we only push if newer?

I'm kind of pushing it to a solution for my current issue which I understand is not the way to go. What I actually would like to have is a mechanism that when executing choco pack will allow me to make a choice based on the package version. (By choice I mean not necessary prompting the user for input but, as above, keep the current behaviour and and extended ones based on parameter or global flags eg.: allowGlobalConfirmation)

Just to give a little bit of context follow my scenario:
Currently I have an automated script that looks up for all \*\*.nuspec files and run cpack against them, after that I run a cpush against the generated packages. The problems is that usually I have changes on only one package to deploy and I end up deploying everything and as my packages are self-contained that represents a few GB's of packages, which would save me a lot of time not publishing the ones I don't need.

Do you think it would be useful to other people as well? Am I overcomplicating it? Does it even make sense what I'm doing? 😝

[ferventcoder]

It might (the --only-if-latest or whatever the option will be called).

[gep13]

@tirolo where are you pushing these packges to? i.e. what are you using to host them? As an interim measure, you could do an md5 hash on the files that are generated by the choco pack, and only push the ones that have changed?

[tirolo]

It's a shared folder in the network then I use the UNC path as the - - source... Works like a charm (I didn't know that would work). I ended up
checking the svn status of the packages folder and doing some sorcery there
to get which packages I have to pack/push... Not really an elegant solution
but makes he process much faster. I think I will change to your suggestion
of md5 so that I don't need to rely on the svn... Thanks for the suggestion
:)
On 30 Nov 2015 7:31 pm, "Gary Ewan Park" [email protected] wrote:

@tirolo https://github.com/tirolo where are you pushing these packges
to? i.e. what are you using to host them? As an interim measure, you could
do an md5 hash on the files that are generated by the choco pack, and only
push the ones that have changed?

—
Reply to this email directly or view it on GitHub
#494 (comment).

[dragon788]

@tirolo If you were using something like Artifactory as your NuGet server it has this intelligence on its side that only stores a single copy of a package with a given hash, and uploading the same hash with a new version just adds an additional tag I think. Typically even the simple NuGet server from Chocolatey/Puppetlabs prevents you from re-pushing the same version a second time without a config change iirc.

It sounds like you are rebuilding every package every time, does this result in the same checksum between runs or do you have a text/nuspec file with a version that gets embedded that would cause the checksums to be slightly different between runs?

If you were using Jenkins as your build server there is actually some path monitoring built in where you could have it only build a path that had changes to the source, but it sounds like you worked it out within your VCS.

[TheCakeIsNaOH]

If the source that you are pushing too is a UNC path, then checking if the package already exists should not be an issue because if choco has permission to access the UNC path to copy the package, then it should be able to read the existing packages from there without issue.

However, if the source is a nuget server, then it may be more complex. For example, if the package is being pushed to a Nexus server, it is possible that choco can pushing using an apikey, but does not have permissions to check the feed for existing packages. Or if the remote source has a different url for pushing as compared to pulling (push.chocolatey.org vs community.chocolatey.org/api/v2, although that specific instance could be hardcoded).

[pauby]

There has been no update to this in some time. I'm going to go ahead and close this, but we can reopen it if necessary.