<!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION --> *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.* <!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION --> ### Problem to solve It adds an artifacts overview page under CI/CD for each project where a user can query artifacts and if he has enough rights he can delete single artifacts or batch delete multiple. (like older than date, or without expiry date) ### Intended users <!-- Who will use this feature? If known, include any of the following: types of users (e.g. Developer), personas, or specific company roles (e.g. Release Manager). It's okay to write "Unknown" and fill this field in later. Personas can be found at https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/ --> [Sasha (Software Developer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sasha-software-developer) ### Further details <!-- Include use cases, benefits, and/or goals (contributes to our vision?) --> because there is no way to manage artifacts now, if they have no expiry date set (like old artifacts), they need to be deleted by API which is not really user friendly. ### Proposal <!-- How are we going to solve the problem? Try to include the user journey! https://about.gitlab.com/handbook/journeys/#user-journey --> This proposal includes a bigger then one milestone scope. Highlighted in __bold__ are items which are closest to the original merge request scope https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/18707 [Screen_Shot_2018-07-05_at_09.07.51](/uploads/6c3263aaf8cf2f15c3d7f544a9c570e3/Screen_Shot_2018-07-05_at_09.07.51.png). Update: https://gitlab.com/gitlab-org/gitlab-ce/issues/66613 fixes part of the currently defined scope Search: - __Job name__ Filter: - Branch - Deleted branches (yes/no, needs deleted branch icon, both for dropdown as well as to showcase which rows are from deleted branches) - __Created date__ - Commit author - __Expired date__ - Pipeline ID - __Size__ - Tag - Trigger author - Trigger source Sort: - Branch - __Created date__ - Commit author - __Expired date__ - Pipeline ID - __Size__ - Tag - Trigger author - Trigger source Other functionality: - __Batch select, including delete all button__ - Recent searches - __Total artifact size depending on filtering__ Shown data per artifact row: - __Job ID__ - __Job Name__ - Triggerer (also called trigger source, can include API, web, push, etc) - Pipeline ID - __Pipeline ref__ - __Commit__ - Commit author - Commit title - __Size__ - __Created time stamp__ - __Expired time stamp__ - Download artifact button - Browse artifact button - Delete artifact button Functionality which is not shown in mockups: - __Total count of selection__ - Pagination, including how this works with batch selecting all currently filtered items across potentially multiple pages (if any).   ### 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)? --> ### 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 --> ### 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/ --> ### 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. --> ### Links / references