Our project overview pages include badges that provide a summary of various CI aspects, such as code coverage, most recent pipeline status, or last release. These badges are not up-to-date with Pajamas standards and are not always clear. They are also not accessible at the moment because of the color contrast. We are updating these to Pajamas badges and adding more helpful information to make them consistent with the ways we present that information elsewhere in the UI.
Problem to solve
Our project overview pages include badges that provide a summary of various CI aspects, such as code coverage, most recent pipeline status, or last release. These badges are not up-to-date with Pajamas standards and are not always clear. They are also not accessible at the moment because of the color contrast.
We use the following hex values to represent different test coverage percentage intervals (see documentation). Users can configure these if they'd like:
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
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.
the problem stated on #225430 is very narrow. This issue proposes bringing a parity in labels and that will allow us to replicate the pipeline status on the project overview page with ease.
@jheimbuck_gl nevermind, I was highly confused around who owns the badges. I'm taking the decisions from the other thread in this issue to the pipeline badge related issue
Hello @jreporter! I would like to work on this issue. This is my first time contributing to an open source project, therefore I need some guidance. Could you please give me information on this issue?
@jreporter@gdoyle these badges currently come from a backend database table. It will take some backend work to get the information we need for these badges to be formatted like we want. The only information we have for each badge currently is the link and the image of the badge. This isn't in a good state for contributors nor is it ready for development.
I will be going through this epic to see which issues are actually ready and are good for contributors.
@nlyyy#328539 (closed) or #338154 (closed) are issues that are ready if you are interested in contributing to other issues for grouptesting specifically. I'm happy to help you out with either. I'm sorry for the confusion.
No worries @shampton, thank you for your suggestions! I'm not looking for anything specific. If you have any more suggestions other than documentation related issues that I can consider contributing to, I would greatly appreciate your help. Thank you again for your time!
This issue's description does not seem to have a section for "Implementation Guide".
Please consider adding one, because it makes a big difference for contributors.
This section can be brief.
It can include any relevant technical tips, like:
Hints on lines of code which may need changing
Hints on similar code/patterns that can be leveraged
Suggestions for test coverage
Ideas for breaking up the merge requests into iterative chunks
!81285 (closed) updated the current badge colors to use Pajamas-compliant ones that match the proposal. We still need to do the following (in follow-up MRs) to achieve the full set of criteria documented in this issue:
these badges currently come from a backend database table. It will take some backend work to get the information we need for these badges to be formatted like we want. The only information we have for each badge currently is the link and the image of the badge.
@gdoyle so it looks like we're using https://shields.io/ to generate these badges. I'm not sure if we're able to customize them to look like our Pajamas badges or not. Our other option would be to move off of them entirely, but to be honest I'm not sure of the extent we are using them.
@andyvolpe do you have any more context on how/why we are using this library? Is it possible to redesign these badges, or are we just able to change the color?
do you have any more context on how/why we are using this library?
These were in use before I started here, so I am not 100% sure as to the why/how outside of speculation.
Is it possible to redesign these badges, or are we just able to change the color?
I believe it is possible, but from my memory of attempting this sometime back, there are a lot of caveats to keep in mind, including the wide range of badges we'd need to support. Addressing the color could be a good start as it would address potential accessibility concerns.
@samdbeckham I remember discussing this with you a few years ago correct me if I am wrong on any points above.
Currently, badges are simple SVG templates app/views/projects/badges/badge.svg.erb, app/views/projects/badges/badge_flat-square.svg.erb without library. But maybe shields.io can be use for others badges in Settings > General > Badges
My current plan is to adapt these templates to something closer to "Pajamas badges" (color+icon). But that means duplicate icons server-side. :/
@samdbeckham I remember discussing this with you a few years ago
@andyvolpe This is very likely, but I have no recollection
I have had a quick look into the code (thanks @ali_o_kan for pointing me in the right direction) and it seems we can update these badges to look however we want. There's a general svg for styling and specific color information for each badge. I can't find any link to shields.io anywhere. @shampton maybe you can help out here.
That video was very helpful @samdbeckham and I think you and @ali_o_kan are definitely right that we can customize these SVGs in those files.
@gdoyle what do you think we should do with these files? Should we create new SVGs that match the Pajamas design but still fall in line with the key/value setup?
@samdbeckham's video definitely helped me understand this more. @shampton So the key and value would always be the same color for a certain object (pipelines vs. code coverage), since we would be using badges rather than something like a scoped label.
I'm not sure if that justifies rewriting the SVGs entirely. I still see value in following the key/value setup. We'd still technically have a key and value, but instead of using the sides of the badges for them, we'd separate them with a :. For example, Pipeline: running. And we'd still want to use the same folder hierarchy, where pipeline has its associated key/value pairs, icons, and colors scoped to the different statuses it shows. For example, Pipeline:running would be blue and use the running icon. Same goes for the other badges that can appear, such as code coverage, which would have its own key/value pairs, icons, & colors.
I realize this issue was solely around updating the test coverage report badge - should I update this to encompass all badges instead? I did not do a full audit of what types of badges can be shown for a project, so I'd want to do that as well to make sure we don't miss anything.
I realize this issue was solely around updating the test coverage report badge - should I update this to encompass all badges instead? I did not do a full audit of what types of badges can be shown for a project, so I'd want to do that as well to make sure we don't miss anything.
Yeah, I think that's a good idea. We can't update just the test coverage report badge alone without affecting all of the other badges.
@shampton Done! I linked to each of the template.rb files and updated the designs so they list all statuses for code coverage, pipeline status, and release status. I'm working on getting final design sign off on pipeline and release badges, but otherwise, they're set
Have we considered what impact these changes will have on users that use the CI badges today? The Pajamas UI makes the look and feel very similar to the Project Labels (see the right sidebar on this issue). What risks can we predict and mitigate to users and the tasks they want to accomplish?
As @shampton pointed out, the badges so we use today are using shields. The way I've seen such badges being used across multiple platforms make them very easy to be recognised because their UI is somewhat similar (example 1, example 2).
@rayana The current badges are not accessible as none of them pass WCAG AA accessibility for color contrast as a background color with #FFFFFF as the foreground color.
The badges should align with the other areas we are showing status. For example, pipeline statuses and code coverage - our pipeline statuses have very specific icons and colors associated with them. It has already caused confusion for users based on #225430. As for the release badges, I'm not as familiar with how many users are using them. For example, GitLab is not using Release badges, only pipeline and code coverage.
I see they are styled the same across other applications, but in this case, I think the pros I mentioned above outweigh the cons.
Thanks for getting back - I will bump the milestone to %Backlog and when you come back to it and move the MR into workflowin review we will pull it back into %14.10
I'm closing this out as we made the decision that the current way these badges are styled is consistent with other platforms and are recognizable by users already. They are also brought in as SVGs and so accessibility is already low. We could consider offering our own styles of these badges in the future, but that should be validated first, and we haven't heard that from users