The Verify:Pipeline Execution Group is focused on all the functionality with respect to Pipeline Execution, as part of GitLab Continuous Integration. This UX team is responsible for the following categories:
In FY23-Q1, we are focused on improving the SUS score of the product by working on the following issues:
The Pipeline Execution design tracking epic and regular syncs are used by the product manager and product designer to keep track of issues that are ready for design, usually aligned to a quarterly theme.
In Pipeline Execution group, design works ahead of development. Therefore, the issues that are being worked on by the designer get assigned to a milestone only after the design proposal has been added, and the status moved from
We dedicate ~10% of our capacity by weight in each milestone to working on UX Debt issues and address them within their SLOs. Read more about the collaboration between UX and engineering on the Pipeline Execution group page.
We use the CI/CD UX Definition of Done (DoD) as a tool for assessing the readiness of an issue and tracking the expected deliverables, objectives, and the approval process.
We use the UX Weight definitions for milestone capacity.
The UX Debt and UI Polish issues for CI are tracked in this epic. Our goal is to work on a minimum of one of these issues each milestone.
|Simplify merge strategies with
||Merge Widget, Settings Page||
|Removing user access to Shared Runners UI||Admin controls||
|Provide visibility for shared runner usage for user namespaces||Merge widget||
|Categorize Permissions||RBAC/User access||
|Re-organize merge strategy/checks options on settings page||Project and Group Settings » General||
There are areas in Pipeline Executions that can be tricky to setup the test data for reviewing the merge request. Depending on the requirement, we clone projects from the CI sample projects pool on the local GDK ot Gitpod instance and test.
Merge requests related to CI/CD minutes and shared runner usage usually require some historical usage data, which can be difficult to set up if it doesn't exist already on the local GDK environment. Below is a video and instructions for how to set that up in under 7 minutes.
Checkout the branch in the MR and open rails console using
bundle exec rails console.
1. Edit CI minutes
ApplicationSetting.current.update(shared_runners_minutes: 400) project = Project.find(20) root_namespace = project.root_namespace namespace_usage = Ci::Minutes::NamespaceMonthlyUsage.find_or_create_current(namespace_id: root_namespace.id) Ci::Minutes::NamespaceMonthlyUsage.update_counters(namespace_usage, amount_used: 100, shared_runners_duration: 100) project_usage = Ci::Minutes::ProjectMonthlyUsage.find_or_create_current(project_id: project) Ci::Minutes::ProjectMonthlyUsage.update_counters(project_usage, amount_used: 100, shared_runners_duration: 100)
:wq to exit the log lines. Do not exit the rails console.
2. Add helper method to rails console
def increase_ci_usage(project:, date:, amount_used:, shared_runners_duration:) date = date.utc.beginning_of_month project_usage = Ci::Minutes::ProjectMonthlyUsage.where(date: date).safe_find_or_create_by(project_id: project.id) Ci::Minutes::ProjectMonthlyUsage.update_counters(project_usage, amount_used: amount_used, shared_runners_duration: shared_runners_duration) root_namespace = project.root_namespace namespace_usage = Ci::Minutes::NamespaceMonthlyUsage.where(date: date).safe_find_or_create_by(namespace_id: root_namespace.id) Ci::Minutes::NamespaceMonthlyUsage.update_counters(namespace_usage, amount_used: amount_used, shared_runners_duration: shared_runners_duration) end
3. Use helper method
increase_ci_usage(project: project, date: 1.month.ago, amount_used: 10, shared_runners_duration: 20)
The usage quota page should now reflect the changes data.
If you wish to educate yourself further around the updates realted to this area, watch this video by our Product Manager, James Heimbuck.