Backend: `release-cli` to extract and validate metadata
Summary
Changing the release-cli
to extract and validate metadata if $CI_SERVER_VERSION \>= X
.
Background
- After enabling the feature flag;
- GitLab will start sending the
--catalog-publish
parameter to release-cli. - release-cli will start sending the
legacy_catalog_publish
parameter astrue
to GitLab. - GitLab continues to publish the catalog as before.
- GitLab will start sending the
- We'll create a new endpoint in GitLab to accept a catalog resource release with calculated/validated metadata parameters.
- We'll implement calculations of metadata in
release-cli
. When the--catalog-publish
flag is passed, do these calculations after the release creation, then start sending a new request to the new API endpoint instead of sendinglegacy_catalog_publish
when creating the release.
Let's assume that we implemented Step 2 (GitLab 17.1) and Step 3 (release-cli 0.18.0). In these scenarios, we have always the latest release-cli (0.18.0).
- GitLab version does not even support
legacy_catalog_publish
(< 16.11).- GitLab does not send
--catalog-publish
. - release-cli only sends a release create request to GitLab.
- GitLab creates the release and publishes the component because it has the old behavior in
Releases::CreateService
.
- GitLab creates the release and publishes the component because it has the old behavior in
- GitLab does not send
- GitLab version does support
legacy_catalog_publish
but does not have the new endpoint of publishing component. (>= 16.11 < 17.1)- When the FF is enabled
- GitLab sends
--catalog-publish
. - release-cli checks
$CI_SERVER_VERSION
. It's < 17.1, so;- release-cli sends a release create request to GitLab with
legacy_catalog_publish
. - GitLab creates the release and publishes the component.
- release-cli sends a release create request to GitLab with
- GitLab sends
- When the FF is disabled
- GitLab does not send
--catalog-publish
. - release-cli only sends a release create request to GitLab.
- GitLab creates the release and publishes the component because it has the old behavior in when the FF is disabled.
- GitLab does not send
- When the FF is enabled
- GitLab version is latest. (>= 17.1)
- When the FF is enabled
- GitLab sends
--catalog-publish
. - release-cli checks
$CI_SERVER_VERSION
. It's >= 17.1, so;- release-cli sends a release create request to GitLab.
- GitLab creates the release.
- release-cli calculates the metadata and sends another request to publish the component.
- GitLab publishes the component.
- GitLab sends
- When the FF is disabled
- GitLab does not send
--catalog-publish
. - release-cli only sends a release create request to GitLab.
- GitLab creates the release and publishes the component because it has the old behavior in when the FF is disabled.
- GitLab does not send
- When the FF is enabled
Proposal
- Create a new endpoint in GitLab to accept a catalog resource release with calculated/validated metadata parameters.
- Implement calculations of metadata in
release-cli
. When the--catalog-publish
flag is passed, do these calculations after the release creation, then start sending a new request to the new API endpoint instead of sendinglegacy_catalog_publish
when creating the release.
Confirm purpose and User Reception (how does this benefit the user?)
This won't affect the users when releasing components.
Other
Some relevant technical details, if applicable, such as:
- Does this need a feature flag?
- Does there need to be an associated instrumentation issue created related to this work?
- Is there an example response showing the data structure that should be returned (new endpoints only)?
- What permissions should be used?
- Is this EE or CE?
-
EE -
CE
-
- Additional comments:
Links/References
Edited by Furkan Ayhan