Download artifact from Jenkins with the BuildMaster extension

Good afternoon everybody,

I have a question regarding the fetching of data from Jenkins through the Jenkins extension.

Our artifacts are located under these url path: http://[server]:8082/job/[application]/[job number]/[artifactory path]$[application-ear]/artifact/

While the Jenkins extension of BuildMaster looks for a path like this: http://[server]:8082/job/[application]/[job number]/artifact/ (missing one part of the URL)

We have checked this in WireShark. The exception we get from BuildMaster is the next one:

DEBUG: Build number is not an integer, resolving special build number "lastSuccessfulBuild"...
INFO: Importing Careunit sonar from Careunit sonar...
DEBUG: Temp file: C:\Windows\TEMP\tmpE224.tmp
DEBUG: Downloading artifact...
ERROR: Unhandled exception: System.Net.WebException: The remote server returned an error: (404) Not Found.
at System.Net.WebClient.DownloadFile(Uri address, String fileName)
at Inedo.BuildMasterExtensions.Jenkins.JenkinsClient.Download(String url, String toFileName)
at Inedo.BuildMasterExtensions.Jenkins.JenkinsBuildImporter.Import(IBuildImporterContext context)
at Inedo.BuildMaster.Windows.ServiceApplication.PlanExecuter.PromotionExecution.Execute()

Thank you in advance!

Nick

Product: BuildMaster
Version: 4.9.1

I've published a new version of the Jenkins Extension (4.7) that logs all URLS, so it might be a little easier to diagnose the specific urls, as it will now be in the log.

If you look at the source code, the entire artifact retreived is "/job/[jobName]/[buildNumber]/artifact/*zip*/archive.zip", and based on the logs, lastSuccessfulBuild is the build number being used.

Not sure if that's helpful though...

tbl_5153

We kinda have the same issue.
We do not use the default setup for artifacts but use a plugin for Jenkins to export to an alternate destination..
It would be nice if you could set the path of the artifact in the extension.
But the path must be able to contain variables that are resolved at runtime, so it might be pretty difficult.

After using some hours trying to solve the issue ald also looking into the extension source we have chosen to add a buildstep to Jenkins where we use
OctoPack to create a nuget package of the deployable artifact and the upload that artifact to Proget.

Now we have applications in Buildmaster that will get the artifact from proget and deploy from there.

You could also add scripting to Jenkins to trigger Buildmaster every time a job in jenkins has succeeded successfully and then it can automagically deploy, but so far we are triggering deployments manually.

Regards
Thomas

Thanks for the feedback; we've been seeing a lot of heavy customizations of CI systems (or ones, like Cruise Control, with no API at all), which makes it challenging for BuildMaster to "pull" build artifacts out.

A big part of our ProGet 4.0 (which is due in just a week or so :D) release will be the idea of a "universal/proget" package type, so it will be much easier to push artifact packages (as easy as zip + cUrl!) and consume them without having to NuGet (which, is really just a zip file with in an awkward protocol/metadata format).

tbl_5153

Releasing Proget 4.0 with the new package type sounds nice and will simplify our deployments significantly (event thou i have everything working in Jenkins in regards to creating nuget artifacts and uploading them to proget).

Looking forward for the new Proget :-)

tbl_5153

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.