## Problem to solve <!-- What problem do we solve? --> For Release Governance, one needs to be able to see what events and actions have been rendered against a release. In https://gitlab.com/gitlab-org/gitlab/issues/26016, we added the capability to create and edit releases, add evidence and additional artifacts to the release via API. Audit logs currently only log `downloading the source code`. This issue is to address expanding the audit logs to include events * [x] `create release` * [x] `create release with milestones` * [x] `edit release event` * [x] `download artifacts in release` * [x] `milestone was associated with release` ## 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. * [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) * [Sidney (Systems Administrator)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sidney-systems-administrator) * [Sam (Security Analyst)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sam-security-analyst) * [Dana (Data Analyst)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#dana-data-analyst) All users who need this info for ** compliance, auditing and monitoring ** of user actions will benefit from this feature. ## Further details <!-- Include use cases, benefits, and/or goals (contributes to our vision?) --> Primary use case for auditing release events include: * Tracking when and who created a release from GitLab after a deployment has occurred * Surfacing records of evidence attached to releases upon request from an auditing firm in the download * Reviewing content of edits with who made the edits to a release in a retrospective ## Proposal <!-- How are we going to solve the problem? Try to include the user journey! https://about.gitlab.com/handbook/journeys/#user-journey --> These audit actions will be implemented, based on the example Release screenshot. - `<name of release>` = "New Release" - `<release number>` = 'v0.3'  Using the screenshot above, can we confirm we need these audit events created: #### Create When a Release is created (via an API call only, at present), Milestone(s) can be optionally associated. There are different messages in the Audit log for Releases created with/without Milestones. ##### Without milestone at create | Author | Action | Target | At | | --- | --- | --- | --- | | `<editor>` | Created Release `<release number>` | `<name of release>` | `<timestamp>` | ##### With milestones at create | Author | Action | Target | At | | --- | --- | --- | --- | | `<editor>` | Created Release `<release number>` with milestones `<milestone>`, `<milestone>` | `<name of release>` | `<timestamp>` | #### Update | Author | Action | Target | At | | --- | --- | --- | --- | | `<editor>` | Updated Release `<release number>`| `<name of release>` | `<timestamp>` | - triggered by a change of the release name or description via the UI or API #### Release - Milestone association change | Author | Action | Target | At | | --- | --- | --- | --- | | `<editor>` | Milestones associated with release changed to `<milestone>` , `<milestone>` , ... `<milestone>` | `<name of release>` | `<timestamp>` | - triggered by a milestone being added to or removed from release (via API only) - see also gitlab#29020 #### Download artifacts | Author | Action | Target | At | | --- | --- | --- | --- | | Orit Golowinski | Repository Download Started | ogolowinski/testing-project | 2019-10-16 16:26:50 UTC | - Already supported #### Future: * [Download external artifacts](https://gitlab.com/gitlab-org/gitlab/issues/194225) * [Delete a Release] (https://gitlab.com/gitlab-org/gitlab-foss/issues/58549) * [Create a Release via UI] (https://gitlab.com/gitlab-org/gitlab/issues/32812) * [Add Assets/Artifacts] (https://gitlab.com/gitlab-org/gitlab/issues/36133) * [Add package] ## 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)?--> * Changes to audit logs should follow the normal access/permissions of Audit Logs at GitLab * Downloads of audit logs should follow the normal access/permissions of Audit Logs at GitLab * Guests/non-GitLab users should not be able to download, edit, or change audit logs ## 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. --> * [Audit Events Documentation](https://docs.gitlab.com/ee/administration/audit_events.html) - for audit events permissions and implementation * [Log System Documentation](https://docs.gitlab.com/ee/administration/logs.html) - Administrations of Audit Logs ## 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/ --> * For the `edit release` item, we would want to make sure we capture what was edited in the release if we do not already - the information captured should be logged and then download capable * This audit log content needs to be `view only` by all users, with `edit log` permissions following the audit log permission structure ## 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. --> * The usage of this feature will be related to the downloads of the audit logs, so we should see an increase in audit log downloads for releases when these items are added * % increase in MAU for release audit logs ## Links / references * gitlab#121 - this API might be leveraged for this issue