Skip to content

MVC: Improve the Artifacts table view to support more data

Problem to solve

The current artifact page does not show enough data to deliver on a meaningful context for users to decide if they need to for example delete it. We've heard from users that additional information that would allow them to trace the artifact back to a pipeline, commit, user, etc. would be helpful when analyzing them. This was noted in https://gitlab.com/gitlab-org/ux-research/-/issues/1679.

Intended users

Proposal

Design

🎨 All screens in design assets

🖌 Figma file screens under "List replacement"

Technical proposal

  • There's no need to introduce a feature flag, we already have one for this page.
  • We can initialize a vue app in place of the current table and build it to match the design with gitlab-ui components.
  • We can use a query like this to get the list of artifacts and their details to populate the table:
query getJobArtifacts {
  project(fullPath: "gitlab-org/gitlab") {
    jobs(statuses: [SUCCESS, FAILED]) {
      nodes {
        status           # job status badge
        name             # job name
        id               # use to get link to job
        
        
        pipeline {
          id             # pipeline
          path           # pipeline link
        }
        
        
        refName          # ref
        refPath          # ref link
        
        shortSha         # sha
        commitPath       # sha link
        
        finishedAt       # time that artifacts were created
        
        artifacts {
          nodes {
            id           # id for deletion
            name         # artifact name
            fileType     # artifact file type badge, flag for whether browse button is shown
            downloadPath # artifact download button link
            size				 # size in bytes
            expireAt     # expire date (ISO)
          }
        }
      }
    }
  }
}
  • And we can use a mutation like this to delete an artifact by id:
mutation artifactDestroy($id: CiJobArtifactID!) {
  artifactDestroy(input: { id: $id }) {
    artifact {
      name
    }
  }
}

Development

GraphQL query to get the job artifacts:

Click to expand 
query getJobArtifacts {
  project(fullPath: "gitlab-org/gitlab") {
    jobs(statuses: [SUCCESS, FAILED]) {
      nodes {
        id
        name
        finishedAt
        refName
        refPath
        shortSha
        commitPath
        artifacts {
          nodes {
            downloadPath
            fileType
            name
          }
        }
      }
    }
  }
}

Includes the following data for job artifacts:

  • total number of artifact files in job
  • job name
  • job status
  • job commit sha
  • job branch
  • job pipeline ID
  • job created at
  • artifact name
  • artifact type
  • download artifact
  • browse archive artifacts

Permissions and Security

Documentation

Testing

What does success look like, and how can we measure that?

We should be able to increase adoption by allowing developers to debug their jobs/pipelines faster.

What is the type of buyer?

Links / references

UX Definition of Done

1️⃣ VALIDATION TRACK

Problem Validation Phase

  • Problem is well understood and has been validated
  • JTBD is well understood and has been validated
  • PM has communicated the opportunity canvas to stable counterparts and group stakeholders, including the Product Designer and Product Design Manager

Design Phase

  • Document the JTBD and UX goal in the issue/epic description
  • Explore multiple different approaches as a team
  • Discuss the technical implications with Engineering
    • Identify any potential cross-team dependencies and include the DRIs in the discussions
  • Identify a small set of options to validate
    • Document the user story(ies) for the MVC
    • Consider edge cases for each user story
    • Create prototypes or mockups for each user story
  • Pajamas component lifecycle
    • Identify component design or pattern update/creation
    • Discuss the technical implications with Engineering
    • Pajamas issue is created (within the scope of the MVC)
  • Update issues/epic descriptions
  • Proposed solution(s) identified and documented in the issue/epic description

Solution Validation Phase

  • Validate the solution to increase confidence in the proposed solution
  • Document the solution validation learnings
  • Product Designer has communicated the solution validation learnings to stable counterparts and group stakeholders, including the Product Design Manager
  • Update the MVC proposal with relevant insights from the solution validation
    • Discuss the technical implications with Engineering
    • Update issue/epic description to contain or link to the findings

2️⃣ BUILD TRACK

Plan Phase

  • Proposal is ready to be broken down and prioritized by PM for development

Develop & Test Phase

  • Product Designer reviewed MRs that include user-facing changes, as per the Code Review Guidelines
    • UX Debt issues have been identified and assigned to a milestone
Edited by Miranda Fluharty