Create artifacts with an external URL at artifact creation

[martinetd]

Hello,

Trying to minimize costs and/or scale to more devices it makes sense to manage artifact data separately from the hawkBit server (assuming the artifact contains no secret and can be made public, or if the update itself is encrypted, or the remote url is authenticated)

I have seen https://github.com/eclipse/hawkbit-extensions/ which has a few alternatives, but these manage files themselves e.g. update artifacts are still uploaded to hawkbit which then re-uploads files elsewhere, it doesn't let someone reuse their current infrastructure.

I've also seen a suggestion of modifying the artifact URL via property around here https://gitter.im/eclipse/hawkbit?at=573f590ce675315635f886ac (e.g. hawkbit.artifact.url.protocols.download-http.ref={protocol}://{hostname}/{tenarollerId}/softwaremodules/{softwareModuleId}/artifacts/{artifactFileName}) but that is common to all artifacts and would impose rigid nomenclature.

In particular in my case, my company provides OS-level updates on our own servers ( https://download.atmark-techno.com ) then our customer is expected to provide their own application-level updates (either upload to hawkbit or on their own servers), so unless I add a redirecting server I can't think of a way to make this work. Is there a variable like artifactFileName that could be used to store the whole URL to use in the hawkbit.artifact.url.protocols.download-http property? Looking at https://github.com/eclipse/hawkbit/blob/master/hawkbit-core/src/main/java/org/eclipse/hawkbit/api/PropertyBasedArtifactUrlHandler.java#L50 I don't see anything that'd work, I thought of using the artifact filename itself as full URL but that field is (rightly!) urlencoded so I can't abuse it.

So to recap my current alternatives would be to either enter fixed URLs and redirect as appropriate or write my own extension, would you have any other/better suggestion?

Thanks!