Skip to content

Can ArtifactoryBuildInfoClient expose response from Artifactory? #31

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
tusharm opened this issue Jun 22, 2014 · 10 comments
Open

Can ArtifactoryBuildInfoClient expose response from Artifactory? #31

tusharm opened this issue Jun 22, 2014 · 10 comments

Comments

@tusharm
Copy link

tusharm commented Jun 22, 2014

Hello,

I am using the build-info-client module to upload content to Artifactory. I noticed that the ArtifactoryBuildInfoClient.deployArtifact() or sendBuildInfo() methods do not expose the response returned by Artifactory API.

This response has some interesting metadata that I'd like to use. Is this something that can be picked up?

@tusharm
Copy link
Author

tusharm commented Jul 29, 2014

Hey guys,

Any plans for exposing Artifactory responses to the clients?

@eyalbe4
Copy link
Contributor

eyalbe4 commented Aug 28, 2014

Hi Tushar,
In order for us to be sure the code changes we're planning to make suit your needs, see the following points and questions:

a. There are two methods in the ArtifactoryBuildInfoClient class for which you'd like us to expose JSon response - deployArtifact() and sendBuildInfo().
As for the deployArtifact(), Artifactory indeed sends the following response that we can easily expose (the method will return it, along with a success/failure indicator, instead of void):

[0] = "repo" -> "libs-snapshot-local"
[1] = "path" -> "/my/groupId/quickstart/4.27-SNAPSHOT/quickstart-4.27-20140828.083720-32.pom"
[2] = "created" -> "2014-08-28T12:00:52.480+03:00"
[3] = "createdBy" -> "eyalb"
[4] = "downloadUri" -> "http://localhost:8081/artifactory/libs-snapshot-local/my/groupId/quickstart/4.27-SNAPSHOT/quickstart-4.27-20140828.083720-32.pom"
[5] = "mimeType" -> "application/x-maven-pom+xml"
[6] = "size" -> "827"
[7] = "checksums" -> size = 2
key: java.lang.String = {java.lang.String@5130}"checksums"
value: java.util.LinkedHashMap = {java.util.LinkedHashMap@5112} size = 2
[0] = "sha1" -> "66325243ae73feca92abb00a3a1d96614913cb22"
[1] = "md5" -> "4287aaafdcab435dffba826a86c8a3c7"
[8] = "originalChecksums" -> size = 2
key: java.lang.String = {java.lang.String@5121}"originalChecksums"
value: java.util.LinkedHashMap = {java.util.LinkedHashMap@5115} size = 2
[0] = "sha1" -> "66325243ae73feca92abb00a3a1d96614913cb22"
[1] = "md5" -> "4287aaafdcab435dffba826a86c8a3c7"
[9] = "uri" -> "http://localhost:8081/artifactory/libs-snapshot-local/my/groupId/quickstart/4.27-SNAPSHOT/quickstart-4.27-20140828.083720-32.pom"

b. For sendBuildInfo() however, Artifactory does not return a JSon response. It only returns an HTTP code that is used by the client as an indication for the success or failure of the build info deployment.
So my question is this - would it be enough for you if the sendBuildInfo() will return a boolean value as an indication for the success of the deployment?

@tusharm
Copy link
Author

tusharm commented Aug 28, 2014

Yes, that seems logical. Thanks!

@eyalbe4
Copy link
Contributor

eyalbe4 commented Aug 31, 2014

The following Jira issue has been opened to track this request:
https://www.jfrog.com/jira/browse/BI-183

@eyalbe4
Copy link
Contributor

eyalbe4 commented Aug 31, 2014

The code has been committed to GitHub.
@tushar, you may test it and provide us with your feedback.

  1. The deployArtifact method in the ArtifactoryBuildInfoClient class now returns a ArtifactoryResponse object.
    The object contains a map with the response content returned from Artifactory (the map's content is described in my previous message above).
    In case of a failure, the method throws IOException (this behavior has not been changed).
  2. The sendBuildInfo method has not been modified. It still returns void. This is because no information is returned by Artifactory as a response to this request. A successful build info publish to Artifactory can be assumed If no IOException is thrown,

@tusharm
Copy link
Author

tusharm commented Sep 2, 2014

Hi,

I just verified that the response contains metadata sent back by Artifactory REST API. Thanks for the change!

I have a comment though. The metadata is being exposed in an un-typed Map. Since the metadata has a nested structure, a Map is not a convenient and type-safe structure to deal with.

It would be great if the ArtifactoryResponse itself has fields (possibly nested) corresponding to properties in the JSON response. This will give the client the flexibility to easily use the response object as they need.

Thx

@eyalbe4
Copy link
Contributor

eyalbe4 commented Sep 2, 2014

Thanks for the feedback Tushar.
I implemented your suggestion and the deployArtifact method now returns an ArtifactoryUploadResponse object containing data members that correspond to the properties in the json returned by Artifactory. The code is committed to GitHub.

@tusharm
Copy link
Author

tusharm commented Sep 6, 2014

Hello,

I tried out the new response object - it works perfect!
Could you tell me when will the release containing this patch be released?

Thx

@eyalbe4
Copy link
Contributor

eyalbe4 commented Sep 11, 2014

Hi Tushar,
The next Build-Info version will be released within the next few weeks. You may however use the committed code in your environment prior to the release. The ArtifactoryUploadResponse class will probably not change till the release and in case we make any change to it, I'll make sure to notify you.
Please let me know if this is okay.

@christopherlebond
Copy link

Hi,

Is it possible to read the ArtifactoryUploadResponse after executing the gradle artifactoryPublish task? We are looking to capture the path of the deployed artefact for later consumption in the gradle script.

Many thanks

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants