Allow different names in grouped pipeline jobs
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.