As a user, I want to edit a Release using the application UI, so that I can have a faster method to quickly manage Releases instead of sending a curl to the GitLab API.
Acceptance criteria
User should be able to edit an existing Release through the Releases page. An edit button should be placed in every Release entry, next to the header. Clicking the button takes the user to a form where it should be possible to edit the information about a Release.
All form items should be pre-populated when user clicks to edit an existing release.
All options from the Create tag form should be available when editing an existing release.
For 12.4, continue using the Tags form to create/edit a Release.
If user has no access rights to manage a create/release, the option to edit it should not be available in the application UI (the button should be hidden).
Once the user edits a Release form field items and submit the changes by clicking the button Save changes, they should be taken back to the Release page, with the item that was updated highlighted on the page (anchored/page scrolled).
A new page should be created for the editing (and eventually creation) of releases as shown in the UX prototypes.
Prototype
Description
Mockup
Releases Page
Edit form, exsisting tag (default)
Edit form, new tag
Edit forn tag dropdown
Dropdown, create tag
Out of scope
User can create a Release through the Releases page.
While editing a Release, the user can remove a release via UI.
Any changes that affect the relationship between releases-tags is not part of the scope for this issue.
Problem to solve
Updating a release if you find a mistake in the content is currently only possible through the Releases API. This would be better if it was available as a front-end feature built in since finding a simple typo and quickly editing it would be a common scenario, as well as getting rid of a release.
Target audience
Release Managers or gitlab-ce9335218 gitlab-ce9335215 gitlab-ce~9335216 who are creating releases and want a better/faster method to quickly edit releases, instead of sending a curl to the GitLab API.
What does success look like, and how can we measure that?
Users will be able to edit Releases using the application UI.
Links / references
This page may contain information related to upcoming products, features and functionality.
It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes.
Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.
Good question @jhampton. I think anyone in the project who can create them should be able to edit them, but not exactly sure who that is today. @dosuken123?
May I suggest that it should be possible for the release author to upload release assets, like when creating a tag, but instead of just appending a link to it in the notes it would create a release link.
Thinking out loud, maybe we should extend this form something like:
git-tag/release CURD form
First section - git-tag:
Name of git-tag (textbox, required) ... The new/existing name of a git-tag.
Create from (textbox, required) ... The git-branch name that will be used for git-tag generation (This parameter is effective when the specified git-tag have not been created yet).
Message (textbox, required) ... The git-tag message (This parameter is effective when the specified git-tag have not been created yet).
Second section - Release:
Do you want to create a Release entry, too? (checkbox, required, default => false) ... If true, then show the following Release creation form.
Name of the release (textbox, optional, default => git-tag name) ... The name of the Release. e.g. "Awesome app v1.0 Beta".
Description of the Release (markdown, optional) ... It's already existing as "Release notes". We just rename the field.
Released at (Datetime picker, option, default => now) ... The release date. It can be past or future (i.e. upcoming-releasse).
Asset type (radiobutton, required, default => Link) ... Users can choose asset type from 1. Link 2. Package (Not supported yet) 3. Docker Registry (Not supported yet)
Name of the link (textbox, required) ... The name of the link (e.g. "awesome-v0.2.msi"). Available when asset type is LINK.
URL of the link (textbox, required) ... The URL of the link. Available when asset type is LINK.
The good thing is, Release entries require git-tag existence anyway (if it doesn't exist, it automatically generates one with the given parameter), which means it'd make sense to have both creation/update form in one form like we do today.
Message (textbox, required) ... The git-tag message (This parameter is effective when the specified git-tag have not been created yet).
I believe lightweight (non-annotated) git tags don't (can't?) have a message. So I'd say this field should not be required.
Also, in general, it would be good if it was made clear to the user from a UI perspective whether an annotated git tag or a lightweight git tag is created. See here for the distinction. This could be done e.g. via checkbox, or a "dynamic" message at the bottom "Annotated git tag will be created" or "Lightweight git tag will be created".
It is not good, in my opinion, if it is not 100% clear to the user which of the two git tags will be created (or if there's any "automatic" non-obvious logic behind it like if the message is empty, it's going to create a lightweight tag, and an annotated tag otherwise), before pressing any "Create" button in the GitLab UI.
Also, in general, it would be good if it was made clear to the user from a UI perspective whether an annotated git tag or a lightweight git tag is created.
That's a good call and totally legitimate. In this issue, we're specifically talking about Release associations, so it's out of scope but we should have an issue for that.
In this issue, we're specifically talking about Release associations, so it's out of scope but we should have an issue for that.
Hmm the issue title is "Make it possible to create or edit a release using the UI" which sounds pretty related to me :-). But you're the GitLab employee - Feel free to open another issue with it and add the relevant tags/links, if needed!
Adding the experience baseline recommendations for Releases as related item gitlab-design#505 (closed). There you can see recommendations for improving the functionality and flow for managing Releases via interface. This is part of the Q3 gitlab-ce2148612 for gitlab-ce2024184. fyi @cstasik
As per discussion documented here gitlab-design#527 (comment 200229013), this issue is part of the gitlab-ce2024184 gitlab-ce2148612 for Q3 and needs to be tackled starting on %12.3 (for UX) and %12.4 for development. @jlenny @cstasik could you look into it so we can ensure our Roadmap for release is updated? Right now the milestone assigned is %12.7.
Added the gitlab-ce2148612 label as this issue is part of the experience baselines effort that impacts the CEO and gitlab-ce2024184 gitlab-design#505 (closed) OKRs
Saving the initial description of the issue in this comment, for posterity:
Problem to solve
Updating a release if you find a mistake in the content is currently only possible through the Releases API. This would be better if it was available as a front-end feature built in since finding a simple typo and quickly editing it would be a common scenario, as well as getting rid of a release.
Target audience
Release Managers or gitlab-ce9335218 gitlab-ce9335215 who are creating releases and want a better/faster method to quickly edit releases, instead of sending a curl to the GitLab API.
Add edit button in UX that will allow a release's elements to be edited visually. The edit should be possible for all users who are able to create releases (developer~admin at time of issue creation)
@jlenny As we discussed, this is the main issue I'd like us to prioritize for Q3. We have the opportunity to improve the gitlab-ce~9335216 experience here, while we finish collecting the necessary information to build the Release Manager persona ux-research#268 (closed).
We already have a set of recommendations to improve the user experience of this functionality. See gitlab-design#505 (closed).
I will work on this issue in the upcoming days so we can discuss it during our %12.4 chat.
This requires gitlab-ce3412464 for sure. The scope atm does not provide enough context for what's needed from gitlab-ce24926493.
@ogolowinski I'm a bit confused as to why the original issue gitlab-foss#56026 (moved) has just been moved to the Backlog. I understand GitLab repositories have moved around, but moving something to the Backlog signals/implies that the work on this has been stopped/postponed. However, hopefully that's not the case, and development has just moved to this issue? It's a confusing signal.
Status update - had a chat with @ogolowinski and made some updates on the scope of this issue.
We will tackle only editing a Release item via UI, since creating it would increase the scope for development. We also have a way to create a Release via ui (through the tags page), and our goal for the next iteration will be improving the Release form to include all attributes found here. https://gitlab.com/gitlab-org/gitlab/blob/master/doc%2Fapi%2Freleases%2Findex.md#create-a-release
User story
As a user, I want to edit a Release using the application UI, so that I can have a faster method to quickly manage Releases instead of sending a curl to the GitLab API.
Acceptance criteria
User should be able to edit an existing Release through the Releases page.
If user has no access rights to manage a create/release, the option should not be available.
All options from the Create tag form should be available when editing an existing release.
All form items should be pre-populated when user clicks to edit an existing release.
@rverissimo thanks for capturing this.
During the chat, we raised another concern (to be handled by a new issue) to log every action done in the release page - currently only downloading the source codes triggers an audit event
After collecting this data, we will need to present it to the user (yet another issue), probably as system notes within an issue
All these "to be handled by a new issue" tasks - creating a release, the audit events etc - is someone actually going to create these issues and schedule them, or how is it going to work?
How about the "We will tackle only editing a Release item via UI, since creating it would increase the scope for development. We also have a way to create a Release via ui (through the tags page), and our goal for the next iteration will be improving the Release form to include all attributes found here"?
Sorry to be so persistent about this but my experience with GitLab (as in "the company") has been that things get buried and forgotten in comments.
@rverissimo I still have some concerns about the proposed prototypes which I detailed here: #31615 (comment 222609088). I won't be able to do any frontend work until these questions are answered.
@nfriend I created a new branch for the backend of this issue: 26016-edit-release-be
Feel free to fetch it and rebase on top of it. Then you'll have access to the Release Edit form page. Use the following URL to access it: http://localhost:3000/<group>/<project>/-/releases/<tag>/edit.