Skip to content

Filter by pipeline IID on Build Artifact page

Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.

Problem to solve

The current artifact page does not provide the user with enough flexibility when filtering. 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 whether or not to delete them or investigating them further. This is an iteration on #33418 (closed).

For filter by branch name, see #367294

Intended users

Proposal

Add filters for pipeline IID (this will be a string, unless it is possible to get suggested results) and branch name (suggested results necessary)

  • add a <gl-filtered-search /> component for filtering by branch name and pipeline IID
  • use the filter data from those components to modify the GraphQL search query and update the list of jobs/artifacts to show the ones that match the filters
  • to search by pipeline IID:
query getArtifacts {
  project(fullPath: "gitlab-org/gitlab") {
    pipeline(iid: "1282711") { # find pipeline with exact iid
      jobs {
        nodes {
          # ...
          artifacts {
            nodes {
              # ...
            }
          }
        }
      }
    }
  }
}
  • to search by branch name:
query getArtifacts {
  project(fullPath: "gitlab-org/gitlab") {
    pipelines(ref: "master") { # filter pipelines by ref
      nodes {
        jobs {
          nodes {
            # ...
            artifacts {
              nodes {
                # ...
              }
            }
          }
        }
      }
    }
  }
}

🎨 Design management

🖌️ Figma file screens under "Filtering"

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

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.

Edited by 🤖 GitLab Bot 🤖