-
Notifications
You must be signed in to change notification settings - Fork 55
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
Support for publish-if-not-exists #86
Comments
Good idea :-) In your custom curl call, are you downloading the repo index and check if it contains the chart, or are you just making a HEAD request to the known location of the chart and check for 404? |
We're using the artifactory storage API to do a
If it succeeds you get back If the artifact does not exist then the response is
|
The complication we have with the above check is that our artifactory is configured to permit overwrites for snapshots but block them for releases (immutable release policy). I haven't checked to see how that plays out for our projects that are using semver but for Ideally this plugin wouldn't try to get involved with all that and just support |
Well, this approach seems pretty specific to Artifactory... so probably each repository type would need its own strategy to do the check. As a default strategy, I suppose checking the index and/or doing a HEAD request to a well-known location should be supported by all repository types. Some custom repositories may not have an index, so we can't rely on that, but always using a HEAD request may also be problematic because the chart .tgz URL is only by convention, the repo index should be the source of truth. As for configuration in the DSL, I suppose there should be a property As for special SNAPSHOT versions, I would like to keep this logic out of the plugin as it seems pretty tied to Artifactory and its Maven heritage. With a If we're downloading and parsing the repo index anyway, we could also use the digest from the repo index for up-to-date checking of the |
This feature would be really nice to have. I think having |
Our artifactory instance implements write-once semantics for final chart versions and will throw an error if you try to publish the same version again. Sometimes we need to re-run a pipeline to resolve an error that came after the chart publication leaving us unable to get past the publication that worked first time.
Currently we work around with an ugly bit of curl in an
onlyIf
attached to the publish task. It would be great if this logic was encapsulated in the DSL.The text was updated successfully, but these errors were encountered: