## Problem to solve In gitlab#26016 we added the option edit a release via UI, and this issue will expand the API `create` functionality into the UI. This issue will cover Create a Release using the Application UI. ## User story As a user, I want to be able to create a release from the Releases page, so I can quickly start managing my releases without having to go to a different page on GitLab. ## Acceptance criteria - If no releases are created, user sees an empty state message. The CTA (call to action) button on the empty state should be removed, and replaced with an inline link to the documentation. - User sees the button `Create release` on the [Releases](https://gitlab.com/gitlab-org/gitlab/-/releases) overview page. - Releases can be created, updated, or deleted by project Developers, Maintainers, and Owners. [See](https://gitlab.com/help/user/permissions#releases-permissions) - If a user doesn't have permission to create a release, the button should not be displayed. - Clicking the `Create release` button should take the user to the `Create tag` page. - In the **Release notes** section of the `Create tag` page, a helper message should be added on top of the text field: - *Optionally, create a public release of your project based on a Git tag. By adding release notes to the tag, the information will be stored in the GitLab database and displayed on the Releases page. [More information]()* - The link should point to the documentation page: https://gitlab.com/help/user/project/releases/index#release-description - If the user fills in the **Release notes** section, and clicks the **Create tag** button, the system should create a new release item. The user will be taken to the detail view of the newly created release tag. (user flow stays as is) ### Out of scope - Any changes relates to the form fields in the New Tag page. - Redirecting the user to the `Releases page` after creating a release tag. - Any other improvements (CSS) to the interface. ## Proposal (UX) * [**SEE PROTOTYPES BY CLICKING THE `DESIGNS` TAB**](https://gitlab.com/gitlab-org/gitlab/issues/32812/designs/release-empty-state.png) ## Intended users * [Rachel (Release Manager)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#rachel-release-manager) * Anyone doing Release manager activities, for example: * [Parker (Product Manager)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#parker-product-manager) * [Delaney (Development Team Lead)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#delaney-development-team-lead) * [Sasha (Software Developer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sasha-software-developer) * [Devon (DevOps Engineer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#devon-devops-engineer) ## Permissions and Security <!-- What permissions are required to perform the described actions? Are they consistent with the existing permissions as documented for users, groups, and projects as appropriate? Is the proposed behavior consistent between the UI, API, and other access methods (e.g. email replies)?--> Releases can be created, updated, or deleted by project Developers, Maintainers, and Owners. Guest users cannot create Releases and should not see the **Create release** button. [Read more](https://gitlab.com/help/user/permissions#releases-permissions) ## Documentation Yes, we will need documentation. <!-- See the Feature Change Documentation Workflow https://docs.gitlab.com/ee/development/documentation/feature-change-workflow.html Add all known Documentation Requirements here, per https://docs.gitlab.com/ee/development/documentation/feature-change-workflow.html#documentation-requirements If this feature requires changing permissions, this document https://docs.gitlab.com/ee/user/permissions.html must be updated accordingly. --> ## Testing <!-- What risks does this change pose? How might it affect the quality of the product? What additional test coverage or changes to tests will be needed? Will it require cross-browser testing? See the test engineering process for further help: https://about.gitlab.com/handbook/engineering/quality/test-engineering/ --> To be determined during the implementation planning. ## What does success look like, and how can we measure that? <!-- Define both the success metrics and acceptance criteria. Note that success metrics indicate the desired business outcomes, while acceptance criteria indicate when the solution is working correctly. If there is no way to measure success, link to an issue that will implement a way to measure this. --> Users will be able to create a Release item from the Release page, via application UI. ## What is the type of buyer? <!-- Which leads to: in which enterprise tier should this feature go? See https://about.gitlab.com/handbook/product/pricing/#four-tiers --> ### Links / references <details> <summary>View previous issue description</summary> Users should be able to: * [ ] Create a Release in the Release Page * [ ] Assign the newly created release it to an existing tag * [ ] Allow manual specifications of milestones * [ ] Support entry in creation of all [attributes from Releases in API]( https://gitlab.com/gitlab-org/gitlab/blob/master/doc%2Fapi%2Freleases%2Findex.md#create-a-release) and support the edit functionality delivered in gitlab#26016: | Attribute | Type | Required | Description | | -------------------| --------------- | -------- | -------------------------------------------------------------------------------------------------------------------------------- | | `id` | integer/string | yes | The ID or [URL-encoded path of the project](../README.md#namespaced-path-encoding). | | `name` | string | no | The release name. | | `tag_name` | string | yes | The tag where the release will be created from. | | `description` | string | yes | The description of the release. You can use [markdown](../../user/markdown.md). | | `ref` | string | yes, if `tag_name` doesn't exist | If `tag_name` doesn't exist, the release will be created from `ref`. It can be a commit SHA, another tag name, or a branch name. | | `milestones` | array of string | no | The title of each milestone the release is associated with. | | `assets:links` | array of hash | no | An array of assets links. | | `assets:links:name`| string | required by: `assets:links` | The name of the link. | | `assets:links:url` | string | required by: `assets:links` | The url of the link. | | `released_at` | datetime | no | The date when the release will be/was ready. Defaults to the current time. Expected in ISO 8601 format (`2019-03-15T08:00:00Z`). | ## Further details #### The Create Release Form should include: [Supporting all attributes from the API](https://gitlab.com/gitlab-org/gitlab/blob/master/doc%2Fapi%2Freleases%2Findex.md#create-a-release) #### Assign newly created Release to Existing Tag * In the create a release using the application UI, there needs to be a separation between `Create Release` and `Create Tag` pages #### Allow manual specification of Milestones Users should be able to specify the Milestone of the Release on the Release page during the `create release` workflow #### Allow manual specification of release date for Releases in gitlab#26413 Users need to be able to manually set the release date for Releases </details>