@mcascone said in Proget: retention policy for branches in a package: This means mybranch and mybranch2 can be reduced to mybranch2. Sorry but wouldn't this be the reverse: *mybranch* will match *mybranch2*? What I mean to say.... because it's an AND conditional, the *mybranch* is effectively ignored. Everything that matches *mybranch2* will also match *mybranch*, but the opposite isn't true. E.g. mybranch1 won't match both conditions. @mcascone said in Proget: retention policy for branches in a package: in this feed, delete matches of 'mybranch', except the latest 3 versions of those matches, which would only impact the versions matching mybranch and leave all other non-matches untouched; Correct. And do note that you can set retention policies to run in dry mode, where nothing is deleted, to verify it's the behavior you want.

Thanks, yeah, that seems to work. I changed my pipeline code to not send any title metadata to ProGet, which returned that field in the UI to its original behavior. I also found that rebuilding an existing package, and sent to ProGet with the updated pipeline, has the same effect.

The groupName refers to the package's group name, and it's optional. A universal package is identified by group + name + version. The files do need to be artifacts; that's what will be zipped up and sent to ProGet.

I ended up using powershell to add variables to a properties file of env.properties. Then used the "inject environment variables" post build step to add the file with those variables to by environment. #Powershell "APP_VERSION=$appVersion RELEASE_NUMBER_VAR=$releaseNumber IIS_APP_ROOT_NAME=$iisAppRootName APP_EMAIL=$appEmail" | Out-File env.properties -Encoding ASCII Then then used the Get-Release API to check and see if my selected release was a valid release. If not I created it with the Create-Release API. Then used the Inedo_BuildMaster Plugin for jenkins. Create BuildMaster Package - Post Build Step Variables: appEmail = ${APP_EMAIL} appVersion = ${APP_VERSION} buildNumber = ${BUILD_NUMBER} buildType = ${BuildTypeParam} iisAppRootName = ${IIS_APP_ROOT_NAME} iisHostNamePrefix = ${BuildTypeParam} After I figured out myself how to inject the Variables and use them properly this rout was much better because it let me know when the package was done deploying, if it failed, showed me the deployment log on failure and failed my Jenkins Job on Failure. Thank you for your answer though Josh!

Thanks, it is working now.

This will be fixed with PG-1313

Hello; just to let you know, the Inedo ProGet Plugin for Jenkins has been updated, and may work better. Have you had an progress onthis otherwise?

The Jenkisn Plugin can only be used to upload Universal Pakages to a Universal Feed. You'll need to use Powershell-Publishmodule command to publish to ProGet.

Hello Bruce, I believe the Jenkins plugin does not want the leading slash on the path, so this should work: parent-folder,myFolder/**/* Let me know if I misunderstood your question - I don't usually work with Jenkins.

Jenkins does not support Windows Integrated auth, so you will need to disable it to get Jenkins to be able to talk to ProGet.

Final results for curl -X PUT... I was able to change C:\Program Files\ProGet\WebApp\Web.config (yes, my server is on Windows 10), and increase the transfer size from 1Gb to 3Gb I then restarted the ProGet Web Service I then tried to upload a zip file 2.02Gb in size..and, it worked.

Great question. First and foremost, if you haven't seen it already, take a read through KB#1056: A Comparison Between BuildMaster vs. Jenkins; it gives a good idea of the differences between release automation and continuous integration. Regarding your question ... What I don't understand is what is the advantage of having BuildMaster take over the pipeline with Jenkins doing the build instead of having Jenkins do it? ... it's really like asking, "what are the advantage of having a people-driven release process instead of having continuous builds automatically tested and then automatically deployed from source to production." The answer really depends on the organization. To many, the idea of continuous deployment is terrifying; for others, it's satisfying. What parts in the Blue Ocean screen shot would still be done in Jenkins and what would be done in BuildMaster? In this case, you would use Jenkins to create a release-suitable build; so your pipeline would look more like Build > Run Unit Test > Run Selenium Test > Export to ProGet > Pull into BuildMaster > Deploy to Integration. The "Deploy to Integration" would be triggering BuildMaster. Of course, Jenkins can deploy (or really, "do anything" since it runs scripts you write) -- but BuildMaster's deployment capabilities will almost always be superior. From there, BuildMaster would handle your release process, and actually get it to the proper environments securely, etc.

I've updated the proget plugin to support pipeline script. It hasn't had a lot of testing (PC died and haven't had a chance to fully rebuilt it yet) but the changes were minimal so should be fine. It's also built against the latest LTS of Jenkins so I hope that won't be an issue for you. I'm also trying to do the same with the BuildMaster plugin but that one is proving to be harder to do and I've had to raise an issue on the Jenkins mailing list.

Alex-Hempel said in Proget Jenkins Plugin: Not working on Slaves?: Caused by: java.io.NotSerializableException: com.inedo.proget.jenkins.DownloadPackageBuilder java.io.NotSerializableException can occur when you serialize an inner class instance because serializing such an inner class instance will result in serialization of its associated outer class instance as well. How to solve it? If the class is yours, make the class serializable by implementing the interface java.io.Serializable. All non primitive members implement Serializable (or are transient instead) If your class is an inner class it's either static or the outer class implements Serializable If the class is 3rd party, but you don't need it in the serialized form, mark the field as transient It is important to note that Serialization of inner classes (i.e., nested classes that are not static member classes), including local and anonymous classes, is strongly discouraged.

Oh ok, I thought it was done by you. I'll pester him about that then. Sorry about that. Thanks, Jon

Hi Stuart Could you let me know the settings you're using in the upload proget package build step in your Jenkins job and if you've changed any of the default settings in the advanced section of the build step? I've not been able to come up with a combination that causes an exception to be thrown in UploadPackageBuilder.java. Regards Andrew

The Jenkins / ProGet Plugin has been updated to Version 0.3 with the following changes: Expand variable correctly Some basic validation on the version number If you update, then it should work!

Alana. I have made a pull request https://github.com/Inedo/bmx-windows/pull/30 Thanks for pointing me in that direction. It was indeed very easy to modify the codebase.

Hm, anything is possible, but I have seen a custom API endpoint causing problems, and a one without privileges set for an API key. Perhaps you can explore the code a little, to see what might be an issue? It's basically just simple HTTP calls to various URLS using Basic HTTP authentication: https://github.com/Inedo/bmx-jenkins/blob/master/JenkinsClient.cs

I think I see why this is happening... it appears the extension is escaping all data in the URI (which would include the equals sign and ampersand): https://github.com/Inedo/bmx-jenkins/blob/956f738173f0cde0ffff4cdef1e6a19ae5e5de66/JenkinsClient.cs#L107 We should be able to fix this and release a new version.