[#118] Spec and schema changes #123
Conversation
doc/spec.adoc
Outdated
|
|
||
| ### Blocking artifact versions | ||
| When using an open channel, a situation may arise where certain artifacts are promoted to the channel and later discovered to be invalid. As it’s impossible to remove artifacts already deployed into a repository, those versions have to blocklisted. | ||
| The blocklist is a separate YAML artifact included in the channel itself. When channel resolves the blacklist artifact, it will always resolve the latest available version. Any changes to the blocked artifact versions can be done independently of channel changes. |
There was a problem hiding this comment.
When channel resolves the blacklist artifact, it will always resolve the latest available version
does it? The block list can be referenced as groupId:artifactId[:version]. It is possible to "stick" to a given version
doc/spec.adoc
Outdated
|
|
||
| #### Resolving channel blocklist | ||
|
|
||
| The blocklist is resolved when a channel is initialized. If no blocklist artifact can be resolved with supplied GAVs, the channel treats it as an empty blocklist. |
There was a problem hiding this comment.
If no blocklist artifact can be resolved with supplied GAVs, the channel treats it as an empty blocklist
shouldn't that be an error? If we specified a GAV for the blocklist, and it is not used (because we did not use the right location), we could eventually pull artifacts that we know are defective... this seems bad
There was a problem hiding this comment.
The use case I had in mind is if there's a channel we know might require blocklist in the future, but initially there's no blocked versions. So rather then having to create a new version of channel definition in future, the initial channel contains a "placeholder" blocklist.
But maybe a better way to do it is to require an empty blocklist to be published
|
@jmesnil I pushed some fixes and added an example doc describing how the channel would be constructed. Looking at the schemas the manifest and blocklist are quite similar. I think by allowing the manifest to accept multiple versions, we could use it for blocklist as well. WDYT? |
I'm not sure. What would it mean for a channel manifest to accept multiple versions? |
|
I think the simplest would be always use the latest listed version ignoring the others. Or if the blocklist should work with concrete versions, it could act as a list of allowed values were the latest, non-blocked one is used |
|
@jmesnil did you have a chance to review the changes to the spec? |
|
included in #109 |
Part of #118