Skip to content
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

check not working for when the resource is used in a get first. #13

Open
shinmyung0 opened this issue Oct 5, 2017 · 1 comment
Open

Comments

@shinmyung0
Copy link

shinmyung0 commented Oct 5, 2017

When the resource is used in a get at the very beginning (first check request) there is nothing passed into the version.version field of the payload so the value of $version becomes empty, which breaks all the downstream logic for determining which url to use etc.

https://github.com/patrickcrocker/maven-resource/blob/master/assets/check#L31

As per the docs on implementing a resource:

  • version is a JSON object with string fields, used to uniquely identify an instance of the resource. For git this would be a commit SHA.
    This will be omitted from the first request, in which case the resource should return the current version (not every version since the resource's inception).

I suppose the only way to get the "current" version would be to do a curl upfront to get the latest version of the artifact that is present in the repository, but I do see how it might be a little tricky if you specify both url and snapshot_url. The way I see it, either we could determine which artifact version to check for the first check depending on which url values are present in the resource, or we could have a param.snapshot field in the get which can be a boolean to explicitly fetch a snapshot version?

Thanks for all the quick responses btw!

@designed4device
Copy link

I ran into this as well. Looks like it would only be a problem when you only have a snapshot url (which is the case for me). I ended up building my own image that uses the snapshot url if release is not present as a temporary workaround.

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

2 participants