### Problem to solve Currently there is the possibility to make sections in the jobs logs collapsible. ``` section_start:<current_timestamp>:<section_name>\r\033[0K [..] section_end:<current_timestamp>:<section_name>\r\033[0K ``` All these sections are then still opened but could be collapsed to make the log better parseable by humans. However sometimes there are very long sections, which just stuff like: * Downloading caches/dependencies * Tests * Long Error/Warning Messages * ... ... which might be great that this is collapsed by default and will be only expanded if the user wants to look into that. ### Intended users Everybody who looks often at jobs logs according to his work. * [Rachel (Release Manager)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#rachel-release-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) * [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) ### Proposal There are 3 different variants proposed: #### 1. An optional parameter area (implemented in !42231) ``` section_start:<current_timestamp>:<section_name>[collapsed=true]\r\033[0K [..] section_end:<current_timestamp>:<section_name>[collapsed=true]\r\033[0K ``` ##### Pro 1. This gives the possibility to add other optional parameters in the future, if required. ##### Con 1. Have to be limited functionally to ensure to not collide with following tokens. 2. Caused by Con 1. maybe harder to implement and quite complex to test. #### 2. An optional suffix ``` section_start:<current_timestamp>:<section_name>[:collapsed]\r\033[0K [..] section_end:<current_timestamp>:<section_name>[:collapsed]\r\033[0K ``` ##### Pro 1. Risk of colliding with other following tokens are low 2. Effort for implementing and testing might be manageable. ##### Cons 1. Not very future proof if other features of the sections might be desired. #### 3. An optional section name marker suffix ``` section_start:<current_timestamp>:<section_name>[_collapsed]\r\033[0K [..] section_end:<current_timestamp>:<section_name>[_collapsed]\r\033[0K ``` ##### Pro See Pro of [2. An optional suffix](#2-an-optional-suffix) ##### Con See Con of [2. An optional suffix](#2-an-optional-suffix), plus: 3. Looks like a lazy solution. :wink: ### Behavior in the UI 1. While the current section is still active: Do not collapse 2. Is the section finished and is marked as `collapsed`: Collapse it. 3. If someone uses a line jump link (like `https://gitlab.com/foo/bar/-/jobs/123#L456`) and this line is inside a collapsed section: Do not collapse also if point 2. happens. ### Permissions and Security No more additional permissions required nor checks. <!-- 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 ~~Right now there seems to be no documentation for sections in GitLab at all. Maybe it worth it to put a small documentation for that in parallel to https://docs.gitlab.com/ee/user/project/pipelines/job_artifacts.html.~~ By now, the documentation for sections was written here: https://docs.gitlab.com/ee/ci/pipelines/#expand-and-collapse-job-log-sections <!-- 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. --> ### Availability & Testing <!-- What risks does this change pose to our availability? 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? Please list the test areas (unit, integration and end-to-end) that needs to be added or updated to ensure that this feature will work as intended. Please use the list below as guidance. * Unit test changes * Integration test changes * End-to-end test change See the test engineering planning process and reach out to your counterpart Software Engineer in Test for assistance: https://about.gitlab.com/handbook/engineering/quality/test-engineering/#test-planning --> ### What does success look like, and how can we measure that? People starting to use this feature (like us) and maybe it will be already used for all standard stuff of the logs like: * `Using Docker executor with image...` * `Fetching changes with git depth set to...` * ... But a statistically logging is hard. <!-- 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. --> ### What is the type of buyer? Tier: Core/Free, Starter/Bronze, Premium/Silver, Ultimate/Gold <!-- Which leads to: in which enterprise tier should this feature go? See https://about.gitlab.com/handbook/product/pricing/#four-tiers --> ### Links / references * gitlab-org/gitlab-foss#14664: Collapsable job log