Allow different names in grouped pipeline jobs

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

• Close this issue

Problem to solve

As a pipeline developer, I want to group jobs with different names so I can more quickly determine the status of specific grouped jobs.

As noted in the documentation, grouped jobs support only the following scenario:

(

That scenario is useful if and only if the grouped jobs are similar and easily identifiable and memorable when identified only by the number. However, this is not always the case, and as a user I do not want to have to dive into the specific job to research what the failure scenario was when I previously could see it at a glance by name alone. Therefore, as a user with complicated pipeline scenarios, I want support for grouped jobs with different names, similar to the following:

(

Intended users

• Delaney (Development Team Lead)
• Sasha (Software Developer)
• Devon (DevOps Engineer)
• Rachel (Release Manager)
• Simone (Software Engineer in Test)

User experience goal

Quickly determine which which job in a complicated grouped pipeline has failed.

Proposal

I have implemented this on my local Gitlab server with the following code in app/models/commit_status.rb:

  def group_name
    #name.to_s.gsub(%r{\d+[\s:/\\]+\d+\s*}, '').strip
    if not name.match(%r{\d+[\s:/\\]+\d+\s*})
      return name
    end
    match = name.match(%r{([\w\s]+)\s+\d+[\s:/\\]+\d+[\s\w]*})
    if not match
      return ""
    end
    return match.captures.first.strip
  end

The intention is to go beyond merely catching a possible group_name, and rather create a firm separation between group_name, which identifies the implied grouping of the jobs, and name, which is the identifier of the jobs. This code identifies the presence of a group name, and then determines the "group name portion" of the name, returning that instead of a straight gsub. This allows the post-numeric portion of the name to act as identifier for the developer.

Further details

This allows me, at a glance, to know that the LTSC build of my smoke tests failed, rather than diving down or being forced to remember that 3/4 is the LTSC version.

Permissions and Security

Documentation

This would necessitate a minor change to the the pipeline documentation here

Availability & Testing

I haven't explored the testing area, I apologize.

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

What is the type of buyer?

Is this a cross-stage feature?

Links / references