Skip to content

Separate Build Artifacts into new categories

Jocelyn Eillis requested to merge jocelynjane-pipeline-reports into master

Background

Build Artifacts are fundamental to the development process. The category covers a vast amount of features: job artifacts, job logs, and pipeline artifacts. In addition, artifacts provide vital internal infrastructure for even more features: API Fuzzing, Container Scanning, Coverage Fuzzing, Dependency Scanning, DAST, Code Suggestions, Secret Detection, etc. Although there are limited opportunities to generate revenue within the category, a poor artifacts experience can lead to customer churn.

Of the approximately 425 issues in the Build Artifacts backlog, we see a breakdown of feature/bug/maintenance of 65/20/15). Each week there is one new issue or support request (via Slack), continuously growing our backlog of bugs. We currently have one senior engineer spending up to 80% of time each week triaging incoming requests and supporting high priority (S2+) tickets in addition to performance-related maintenance work.

With Build Artifacts in maintenance mode for FY24, we are limited to the number of bug fixes we can accommodate and new features have been paused. The last feature release was in 16.1 for the Artifacts page. Per customer feedback, there is a high desire to add search, filtering, and sorting to enable better storage management; lack of these capabilities have been pain points for customers. This has also limited rollout of storage limit enforcement as users are unable to reasonably manage their storage.

By strategically re-distributing Build Artifacts ownership into separate categories/features, we have the opportunity to make a collective improvement in this area in a shorter amount of time. Frequently context switching between Secrets Management and Build Artifacts has led to inefficiencies within Pipeline Security.

Note: In addition to the backlog, there are 100 test related issues. This backlog of tests should also be evaluated to ensure robust, efficient testing to catch bugs prior to release.

Proposal Details

Divide the responsibilities for the current Build Artifact category into the following three categories:

  • Secure Artifacts
  • Job Artifacts
  • Pipeline Reports

Secure Artifacts

This category is focused on hardening of artifacts, to ensure the authenticity of artifacts. Examples of ownership for Secure Artifacts include:

  1. Signed artifacts
  2. Tamper-proofing of artifacts
  3. Notification of tampering/potential security breach of artifacts (i.e. counterfeit signature)
  4. Authentication of artifacts
  5. Artifact access and restrictions

The statement of work for Secure Artifacts aligns with the Pipeline Security group, and should remain with the team for ownership responsibility.

Job Artifacts

This category focuses on user needs of artifacts which are created as an output of a pipeline or job. This includes both the job’s artifacts, job logs and pipeline artifacts.

Consider artifacts as the layer to store and manage pipeline binaries, both job and pipeline artifacts. Artifacts storage and management go together because it's about creating and deleting artifacts.

Specific examples of ownership:

  1. Features for manageability of job artifacts, job logs, and pipeline artifacts (i.e. sorting, filtering, pagination)
  2. Storage accuracy and notification (e.g. storage limits)
  3. Usage and display of artifacts. Currently only job artifacts but if pipeline artifacts affect the storage usage, users should have visibility into that too.
  4. Rolled up insights tied to job artifacts such as dashboards that are meaningful to customers in this area.
  5. Transferring of artifacts with object storage

Pipeline Reports

The framework to generate various report types based on job artifacts. Pipeline reports can leverage Pipeline Artifacts as a storage mechanism for aggregating results or persist data with a database schema.

Reports "use" pipeline artifacts as a storage mechanism but operates at a higher level than artifacts.

Specific examples of ownership:

  1. Maintain the framework code for CI reports in general, empowering teams to register and maintain new report types.
  2. Organization of Pipeline Reports for Code Coverage (i.e. parent-child reporting)
  3. Dashboards/Analytics/Insights based on test results
  4. Parent-child report support. Since this can affect multiple report types, it should be a behavior supported by the CI reports framework.

Both Job Artifacts and Pipeline Reports will be owned by Pipeline Execution, as the customer experiences and JTBD's align best here.

Approvals

Merge requests with changes to stages and groups and significant changes to categories need to be created, approved, and/or merged by each of the below:

  • Chief Product Officer @david (post MR link in chief-product-officer once all others have approved and tag Gena Schwam in slack) @gschwam for triage on behalf of David
  • PLT Leader relevant to the affected Section(s) @steve-evangelista OR @hbenson OR @mflouton OR @justinfarris
  • The Product Director relevant to the affected Section(s)
  • The Engineering Director relevant to the affected Section(s)
  • Director of Product Design @vkarnes

Note:_ Chief Product Officer approval should be requested once all other approvals have been completed. To request approval, post the MR link in the #chief-product-officer channel tagging @david and cc'ing @Gena Schwam._

The following people need to be on the merge request so they stay informed:

  • Chief Technology Officer @sabrinafarmer
  • Development Leader relevant to the affected Section(s) @timzallmann OR @bmarnane OR @meks
  • VP of Infrastructure & Quality Engineering @meks
  • VP of UX @ampesta
  • Director of Technical Writing @susantacker
  • Engineering Productivity (by @ mentioning @gl-quality/eng-prod)
  • The Product Marketing Manager relevant to the stage group(s)

After Approvals and Merge

  • Create an issue in the gitlab-org/quality/triage-ops project to update GitLab Bot automation:
  • Rename Slack channels to reflect the new category/stage/group name
  • Open an MR in the gitlab-org/gitlab project to update any reference of the previous group label to the new one
  • Mention the product group Technical Writer to update the documentation metadata
  • Share MR in #product, #development, #g_engineering_analytics and relevant #s_, #g_, and #f_ Slack channels
  • Review direction pages, groups, projects, epics, issues, templates and documentation to ensure the name change is applied consistently
  • (for group change only) Update the event and metric definitions belonging to the group by following this guide
Edited by David DeSanto

Merge request reports