WIP: Add API endpoint to get single release by id
What does this MR do?
A PoC to introduce GET /projects/:id/releases/:release_id
and deprecate GET /projects/:id/releases/:tag_name
.
Add id
to release entity.
Does this MR meet the acceptance criteria?
Conformity
-
Changelog entry -
Documentation created/updated or follow-up review issue created -
Code review guidelines -
Merge request performance guidelines -
Style guides -
Database guides -
Separation of EE specific content
Performance and testing
-
Review and add/update tests for this feature/bug. Consider all test levels. See the Test Planning Process. -
Tested in all supported browsers
Security
If this MR contains changes to processing or storing of credentials or tokens, authorization and authentication methods and other items described in the security review guidelines:
-
Label as security and @ mention @gitlab-com/gl-security/appsec
-
The MR includes necessary changes to maintain consistency between UI, API, email, or other methods -
Security reports checked/validated by a reviewer from the AppSec team
Closes #56838 (closed)
Merge request reports
Activity
changed milestone to %11.11
added Category:Release Orchestration Deliverable UX awaiting feedback backend devopsrelease [DEPRECATED] direction frontend permissions + 1 deleted label
Actually, should we just support a filter option to
releases
?desc 'Get a project releases' do detail 'This feature was introduced in GitLab 11.7.' success Entities::Release end params do optional :id, type: Interger, desc: 'The id of releases' use :pagination end get ':id/releases' do releases = ::ReleasesFinder.new(user_project, current_user, params).execute # and filter results by the parameter present paginate(releases), with: Entities::Release, current_user: current_user end
BTW, when do users use this
GET /releases/:tag_name
today? IIRC, it's not used for frontend.Given
PUT/POST /projects/:id/releases/:tag_name
will stay intact, we might want to keep theGET /projects/:id/releases/:tag_name
for the consistency sake. With the above approach, we don't break anything.Edited by Shinya Maeda
removed UX + 1 deleted label
mentioned in issue #56838 (closed)
3 Warnings ⚠ Most of the time, merge requests should target master
. Otherwise, please set the relevantPick into X.Y
label.⚠ CHANGELOG missing. You can create one with:
bin/changelog -m 27697 "Add API endpoint to get single release by id"
If your merge request doesn’t warrant a CHANGELOG entry,
consider adding any of the ~backstage, ci-build, ~Documentation, meta, QA, test labels.
See the documentation.⚠ This merge request is missing the ~Documentation label. 1 Message 📖 This merge request adds or changes files that require a review from the Technical Writing team. Documentation review
The following files require a review from a technical writer:
doc/api/releases/index.md
doc/api/tags.md
The review does not need to block merging this merge request. See the:
- DevOps stages for the appropriate technical writer for this review.
- Documentation workflows for information on when to assign a merge request for review.
Reviewer roulette
Changes that require review have been detected! A merge request is normally reviewed by both a reviewer and a maintainer in its primary category (e.g. frontend or backend), and by a maintainer in all other categories.
To spread load more evenly across eligible reviewers, Danger has randomly picked a candidate for each review slot. Feel free to override this selection if you think someone else would be better-suited, or the chosen person is unavailable.
Once you've decided who will review this merge request, mention them as you normally would! Danger does not (yet?) automatically notify them for you.
Category Reviewer Maintainer ~Documentation Mike Lewis ( @mikelewis
)backend Imre Farkas ( @ifarkas
)Stan Hu ( @stanhu
)Generated by
🚫 Danger@krasio Thanks. I left a couple of thoughts.
assigned to @krasio
AFAIK, there are no guidelines to deprecate a thing (we might already have and I'm just not aware of it).
Basically, what needs to be done is
- Documentation
- Blog post
- (Optional) Warning message in the interface (e.g. KubernetesService)
- (Optional) Warning message in the application log
- (Optional) Feature flag to fallback to the legacy behavior