### Release notes When viewing job logs today, there are no timestamps included so it's difficult to identify how long a section of that job took. You can now use timestamps in a log to identify bottlenecks and optimize job performance. ### Problem to solve Originally identified in: https://gitlab.com/gitlab-org/gitlab/-/issues/202293. When running CI, it is impossible to find which parts of the job take the longest, and therefore difficult to identify what needs to be optimized. * **JTBD:** Optimize deployments. * **User story:** As a CI user, I can look at a job log and determine which section of the job is the largest bottleneck, so that I can optimize that section. ### Intended users Job optimizer - any persona using CI jobs. ### User experience goal The user should be able to look at a CI job log and determine what the bottlenecks are so they can optimize those sections. ### Proposal **Acceptance criteria** * Implement behind FF `FF_TIMESTAMPS` * Round timestamps to seconds only, do not include the date (we will have to add a tooltip to the `finished relative time` in the job details - there's already a date tooltip when hovering over the `created relative time` - we need this to account for edge cases where the job runs past midnight). * Timestamps should use [ISO 8601 absolute format for time](https://design.gitlab.com/content/date-and-time#absolute-format). * Wrap job output underneath itself, meaning the timestamp will be a fixed column.  **Design resources** * [Figma file](https://www.figma.com/design/4Pr5dZdVHrN0GlnqoxBkHu/Runner-Core?node-id=0%3A1&t=JYqw4GzGIMZrunP6-1) **Future iteration ideas:** * Allow users to show/hide this on any job log (need to figure out if this can work while jobs are running, or if we have to wait for the job log to finish). * Move times for collapsible sections closer to the timestamps. * Since [pipeline traces will become generally available in the near future](https://gitlab.com/gitlab-org/gitlab/-/issues/460800 "Discuss: Tracing and Pipelines integration for CI/CD debugging/optimization use cases"), **we need to think about the value of timestamps in logs vs. using pipeline traces would weigh against each other**. **Pipeline traces will point out bottlenecks in a whole pipeline**, giving the user the ability to examine the inner<span dir=""> </span>sections of a job and even compare them with other jobs in the pipeline. This seems to be a **more complete experience than examining a single job** and having to do math to figure out the time it took for an individual section in a single job, and then repeating this with other sections in the job or even perhaps other jobs in the pipeline. <details> <summary>Previous proposals</summary> As the timestamps for each log line can be provided by the backend, we are able to display them in our logs where present, for example:  </details> ### Further details Customer verbatim: * “When someone complains that a particular stage in Jenkins (job in GitLab) takes too long, how do we debug that? How do I analyze how much of the execution was spent downloading dependencies, vs how much time was spent compiling the code? If the lines had timestamps, I could determine exactly where the bottleneck lies.” * “When running tests, sometimes there is a single test which takes far longer than others. Users complain about testing taking too long and now we need to debug this. In order to determine which test is hanging or taking the largest amount of time, if I could go through the execution logs and see timestamps, I could find the test cmd where things take longer than expected and then debug that.” * “This is a small scale example, but real world: In my (terratest:eks)\[https://gitlab.com/sandlin/aws/terraform_eks/-/jobs/563074542\] stage, I can see go test ... takes 6:13, but what part is taking so long? Is it the tests? Is it the dependency download? etc.” ### Permissions and Security ### Documentation ### Availability & Testing ### Available Tier ### Feature Usage Metrics * Track the number of users who enable the FF. ### What does success look like, and how can we measure that? * We should see users enabling the FF. * We should see less users relying on workarounds or third-party tools to add timestamps. * We should hear less users needing this feature, improving their migration process from other CI tools to GitLab. ### What is the type of buyer? ### Is this a cross-stage feature? Yes - ~"group::runner", ~"group::observability", ~"group::pipeline execution", ~"group::pipeline authoring" ### What is the competitive advantage or differentiation for this feature? ### Links / references _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._ _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._ _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._ _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._ _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 --> *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 -->