Add optional name qualifier to location objects in ArtP #249
Conversation
|
@e-backmark-ericsson, @k-hallen-ericsson, here's a PR for the multi-file artifact thing we talked about on Slack. |
t-persson
requested review from
d-stahl-ericsson,
t-persson,
e-backmark-ericsson and
k-hallen-ericsson
With the addition of data.locations.name it'll be possible to connect a URI in an ArtP event to the corresponding file in a multi-file ArtC event. If this connection can't be made multi-file artifacts force consumers to use heuristics to figure out how to download a particular file.
magnusbaeck
force-pushed
the
location-name
branch
from
56434d1
to
97af736
Compare
|
@d-stahl-ericsson, @k-hallen-ericsson, @e-backmark-ericsson, could I ask either of you to have a look at this PR? Our pipeline relies on multi-file artifacts and without an unambiguous way of publishing the URLs to the files we'll have to resort to workarounds. |
|
If I understand this right this is not a duplication of data, data.fileInformation.name in ArtC can be a list, here you point to a specific entry in that list. Will approve. |
Correct; it's basically a foreign key into ArtC's data.fileInformation array. Thanks for having a look! Do you think Emil or Daniel wants to review it as well or are we ready to merge this? |
|
Looking at it now |
|
LGTM |
…nity#249) With the addition of data.locations.name it'll be possible to connect a URI in an ArtP event to the corresponding file in a multi-file ArtC event. If this connection can't be made multi-file artifacts force consumers to use heuristics to figure out how to download a particular file.
Applicable Issues
Fixes #248
Description of the Change
We add
data.locations.nameto ArtP to make it possible to connect a URI to the corresponding file in a multi-file ArtC event. If this connection can't be made multi-file artifacts force consumers to use heuristics to figure out how to download a particular file.Alternate Designs
We assume that the
data.fileInformation.namevalues in ArtC are unique so that the URI mapping can be unambiguous. Introducing an independent artifact file ID in ArtC (perhaps UUID-based) we would've addressed that, but it's not clear that it's worth it. Ambiguous filenames in ArtC are problematic for other reasons.Benefits
Multi-file artifacts become usable in practice without having to resort to heuristic-based mapping of URIs to files.
Possible Drawbacks
None as far as I can tell.
Sign-off
Developer's Certificate of Origin 1.1
By making a contribution to this project, I certify that:
(a) The contribution was created in whole or in part by me and I have the right to submit it under the open source license indicated in the file; or
(b) The contribution is based upon previous work that, to the best of my knowledge, is covered under an appropriate open source license and I have the right under that license to submit that work with modifications, whether created in whole or in part by me, under the same open source license (unless I am permitted to submit under a different license), as indicated in the file; or
(c) The contribution was provided directly to me by some other person who certified (a), (b) or (c) and I have not modified it.
(d) I understand and agree that this project and the contribution are public and that a record of the contribution (including all personal information I submit with it, including my sign-off) is maintained indefinitely and may be redistributed consistent with this project or the open source license(s) involved.
Signed-off-by: Magnus Bäck <magnus.back@axis.com>