-
Bug
-
Resolution: Unresolved
-
Major
-
None
I'm not sure if this is a bug or just a misunderstanding. I posted a comment on the wiki page for the plug-in but I'm not sure how often that gets checked and is appropriate:
On the project and build pages, a list of URL(s) is displayed for each deployed artifact. From the source code:
src/main/resources/org/jenkinsci/plugins/artifactdeployer/DeployedArtifacts/summary.jelly:
<a href="deployedArtifacts/download/artifact.${artifact.id}/">${h.escape(artifact.remotePath)}</a>
src/main/resources/org/jenkinsci/plugins/artifactdeployer/ArtifactDeployerProjectAction/jobMain.jelly:
<a href="${lastSuccessfulNumber}/deployedArtifacts/download/artifact.${artifact.id}/">
Isn't the URL on the Jenkins master at .../deployedArtifacts/download/... always invalid? What is the purpose? It seems that users will click on this can get confused by the HTTP 404 error.
[JENKINS-15121] Invalid URL's on Project/Build pages for deployed artifacts
pickgr
created issue -
Gregory Boissinot
made changes -
| Status | Original: Open [ 1 ] | New: In Progress [ 3 ] |
pickgr
added a comment - For our specific scenario, we are using shared NFS storage for our artifacts. We have a simple apache front-end setup for users to browse/download the artifacts so we don't place any extra burden on our Jenkins masters.
We also have a geographically diverse build environment with masters and slaves distributed at different sites around the world - sometimes the master and slave is not co-located. The slave will always upload it's artifacts to the local "artifact server" which is essentially a NAS with a web front-end.
So for our rather complicated environment, we need to provide a URL to the artifacts based on where the slave is located. Ideally, what we need is a way to configure a URL that is based on some environment that is slave-specific.
For now, we've just modified the jelly so that the artifacts are just listed without a hypertext reference. If there was a way to just turn this off globally without having to hack the jelly files, that would be a big improvement for us.
Thanks for your consideration.
pickgr
added a comment - For our specific scenario, we are using shared NFS storage for our artifacts. We have a simple apache front-end setup for users to browse/download the artifacts so we don't place any extra burden on our Jenkins masters.
We also have a geographically diverse build environment with masters and slaves distributed at different sites around the world - sometimes the master and slave is not co-located. The slave will always upload it's artifacts to the local "artifact server" which is essentially a NAS with a web front-end.
So for our rather complicated environment, we need to provide a URL to the artifacts based on where the slave is located. Ideally, what we need is a way to configure a URL that is based on some environment that is slave-specific.
For now, we've just modified the jelly so that the artifacts are just listed without a hypertext reference. If there was a way to just turn this off globally without having to hack the jelly files, that would be a big improvement for us.
Thanks for your consideration. 
Ben McDonie
added a comment - I use this plugin for all my deployments, and it works great.
I have one feature request that is related to this issue. It would be nice if I could configure 2 different paths... (1) The path the building node actually copies to, and (2) the path that the build page URL references.
Why do I want this?
My Jenkins master is on a Windows Server node. Many jobs build on a Mac slave node. The common location for our deployed artifacts is on a network share that we commonly access in Windows environments via \\server\share notation. On the mac, however, we simply mount the directory and deploy to /Volumes/share. Basically, each node has an env variable that uses the appropriate directory string for its environment so that all builds deploy to ${DEPLOY_PATH}/builds/${BUILD_NUMBER}/so-on-so-forth.
With this strategy, the execution of the builds work great ... in BOTH environments. The issue is the URL to the deployed artifacts on the build page. When it was built on the windows machine, the URLs look like "\\server\share" and users can click them with success. When the mac did the build, the URL says "/Volumes/share/..." and they do not work.
Could the plugin be modified in such a way to allow a workaround to this issue?
Ben McDonie
added a comment - I use this plugin for all my deployments, and it works great.
I have one feature request that is related to this issue. It would be nice if I could configure 2 different paths... (1) The path the building node actually copies to, and (2) the path that the build page URL references.
Why do I want this?
My Jenkins master is on a Windows Server node. Many jobs build on a Mac slave node. The common location for our deployed artifacts is on a network share that we commonly access in Windows environments via \\server\share notation. On the mac, however, we simply mount the directory and deploy to /Volumes/share. Basically, each node has an env variable that uses the appropriate directory string for its environment so that all builds deploy to ${DEPLOY_PATH}/builds/${BUILD_NUMBER}/so-on-so-forth.
With this strategy, the execution of the builds work great ... in BOTH environments. The issue is the URL to the deployed artifacts on the build page. When it was built on the windows machine, the URLs look like "\\server\share" and users can click them with success. When the mac did the build, the URL says "/Volumes/share/..." and they do not work.
Could the plugin be modified in such a way to allow a workaround to this issue? We have exactly the same issue. On our project summary page, there is a "Last Successful Deployed Artifacts" section that provides a hyperlink to the artifact - in this case, an Android APK.
The hyperlink text is correct: /Volumes/hdrive/builds/2014/Android/OurApp/OurApp-Build-12.apk
The hyperlink URI is not: http://our.jenkins.server:8080/job/OurApp-Android/12/deployedArtifacts/download/artifact.1/
The URI should actually be the file equivalent of the text, something like: file://Volumes/hdrive/builds/2014/Android/OurApp/OurApp-Build-12.apk
I'm not really sure what editing a jelly is, but I'm sure we can hack something to fix this. But there is clearly an issue with invalid URLs, so I have upvoted this bug and am watching. Thanks!
Jeff Ishaq
added a comment - - edited We have exactly the same issue. On our project summary page, there is a "Last Successful Deployed Artifacts" section that provides a hyperlink to the artifact - in this case, an Android APK.
The hyperlink text is correct: /Volumes/hdrive/builds/2014/Android/OurApp/OurApp-Build-12.apk
The hyperlink URI is not : http://our.jenkins.server:8080/job/OurApp-Android/12/deployedArtifacts/download/artifact.1/
The URI should actually be the file equivalent of the text, something like: file://Volumes/hdrive/builds/2014/Android/OurApp/OurApp-Build-12.apk
I'm not really sure what editing a jelly is, but I'm sure we can hack something to fix this. But there is clearly an issue with invalid URLs, so I have upvoted this bug and am watching. Thanks! 
Manuel
added a comment - What is the current state here? | Workflow | Original: JNJira [ 145841 ] | New: JNJira + In-Review [ 185426 ] |
A slave node might be off when you want to access a deployed artifact.
Therefore, I suppose all artifacts deployed have to be accessible from the Jenkins master.
What do you think?