<!--IssueSummary start--> <details> <summary> Everyone can contribute. [Help move this issue forward](https://handbook.gitlab.com/handbook/marketing/developer-relations/contributor-success/community-contributors-workflows/#contributor-links) while earning points, leveling up and collecting rewards. </summary> - [Work on this issue](https://contributors.gitlab.com/manage-issue?action=work&projectId=278964&issueIid=17941) - [Close this issue](https://contributors.gitlab.com/manage-issue?action=close&projectId=278964&issueIid=17941) </details> <!--IssueSummary end--> ### Description **Improving team collaboration and transparency** Essential visibility for teams working together on shared CI/CD pipelines. Reduces friction, eliminates mystery cancellations, and helps teams collaborate more effectively. I'd like to know who cancelled my pipeline. For all other actions/events that you would like to see in the UI. Please leave a comment in https://gitlab.com/groups/gitlab-org/-/epics/14183 ### Proposal Gitlab should log, along with the status on the build/pipeline history, the user (if applicable) that caused the cancellation for improved coordination in the team, especially in large organizations. ### Workaround for ~&quot;self-managed&quot; admins ``` grep -E 'caller_id":"Projects::(Jobs|Pipelines)Controller#cancel' /var/log/gitlab/gitlab-rails/production_json.log \ | jq --raw-output '[.time, ."meta.user"] | @tsv' \ | grep …job…or…pipeline…id… | sort ``` ### Customer Verbatim "We have had automated release jobs canceled and we have no idea who canceled them. We are unable to prevent this from happening without knowing who" ""It hinders pipeline investigations - our SRO pipelines are quite long so when they get cancelled (accidentally? on purpose?) it makes life a lot harder when I don't know who did it and why." Also see [customer impact](https://gitlab.com/gitlab-org/gitlab/-/issues/17941#note_3015432631) ### Implementation guide For the MVC we should look at focusing on only single-pipeline views. #### Frontend ~frontend **Location one:** In `app/assets/javascripts/ci/pipeline_details/header/pipeline_header.vue` add `canceled by user <username>` after the duration text. According to the [design](https://gitlab.com/gitlab-org/gitlab/-/issues/17941/designs/on-pipeline-detail-page.png) We use the GraphQL query `app/assets/javascripts/ci/pipeline_details/header/graphql/queries/get_pipeline_header_data.query.graphql` to get data so we will need ~backend to implement a way for us to determine who cancelled the pipeline. Add test coverage! **Location two:** In `app/assets/javascripts/ci/common/pipeline_summary/pipeline_summary.vue` add `canceled by user <username>` according to the [design](https://gitlab.com/gitlab-org/gitlab/-/issues/17941/designs/on-commit-page.png) We use the GraphQL query `app/assets/javascripts/ci/common/pipeline_summary/graphql/queries/get_pipeline_summary.query.graphql` for fetching data. It's the same GraphQL type as location one in the UI so ~backend can make only one change to support this feature. Add test coverage! #### Backend ~backend Per the discussion in https://gitlab.com/gitlab-org/gitlab/-/work_items/17941#note_3107266630 We need to create another table - https://docs.gitlab.com/development/cicd/cicd_tables/ that'll track 1. Who canceled the build. 2. Port over the columns 1. Erased by ID 2. Erased at 3. Auto Canceled by ID 4. Auto Canceled by Partition ID Then by using this data, and some custom logic (eg disregard allowed_to_fail jobs), we cache these results on the pipeline level. See [`Gitlab::Ci::Status::Composite`](https://gitlab.com/gitlab-org/gitlab/-/blob/83cd07b4164743fc1ef0470ebe52e2a211a85e2a/lib/gitlab/ci/status/composite.rb) for how statuses are aggregated. We can additionally expose this via the API. The first step we need to do is 1. Create the new table 2. Add the data of who canceled the build when the build is canceled Then pass this issue to ~"group::ci platform" to finish the porting Feature flag all of this - to test performance implications