Gitlab Filter Extension: Part 1 — Finding an issue and discovering if we can fix it with coding
I maintain a Self-Hosted Gitlab server for my company, and whenever there’s a new release announced, I check Gitlabs’ Release Blog, to see what’s new and what affects my tier. But there’s no option to filter the features to my tier, so I lose a considerable amount of time reading through nice features that don’t actually apply to my reality.
TL;DR: I’ve created an extension to help filter out non-applicable updates to my gitlab instance tier, so I can focus on what’s new for me; I’m sharing the knowledge and process as part of a small series of medium posts.
Why?
So why go to all this trouble you may ask? Because we can, as developers, we spend our time solving the issues of others, we can also, with some effort solve the ones that are bothering us as well :D
How?
So how could we solve this issue?
- We could send a message to the Gitlab Blog maintainers and ask them?
- We could open a ticket in the site project requesting a new feature to add a filter to those type of blog posts.
- We could also just open the source code and find the files that represent blog posts, and send a patch and ask them to accept.
- Or…
- We can remove Gitlab from the equation and just create a piece a code that solves a problem for us
By removing Gitlab from the decision we can, with a bit of effort, create a small focused piece of code that solves a simple problem, without needing to know how the whole architecture of their site is structured and without having to wait for them to decide this is something they actually want.
Analyzing the issue
Looking at the DOM structure of the blog, we can see that all the features are in a grid with a row and two columns, when the feature is a primary feature we have it uses the whole row, by placing the feature information in one column and the description on the other.
As with any other real project, we must first try to fail at attempting to solve the core functionality, which is to be able to correctly assert if a feature is enabled for a specific tier and license.
Looking at their Badges we can see that they separate into two tiers, the one that runs on their clouds (SaaS) and the one that are self-hosted (Self-Managed), and for them they also have the licensing levels, FREE, PREMIUM and ULTIMATE, they also will visually show for which tier and license the feature is available. This is a stellar job by the Gitlab team, it’s easy to see what applies to you or not, and advertises what you are missing out on :D
When we take a closer look at the badge code, we can see that it follows a nicely defined structural Hierarchy, inside a badge-container we have two badge-container-type divs that have the tier information presented as text, and right underneath we have 3 <a> tags that represent the badges, we can see that the license level is in a div with the class badge and the ones that are available for that license has the class available , props to the Gitlab team for not obfuscating the classes and making them semantically meaningful
Now that we know that all the information we need is available on the page we can breakdown what we need to do in small pieces:
- Find the node in the DOM with the tier information (SaaS and Self-Managed)
- For each tier, evaluate the badges for each license and find the ones that are available, given a valid license value (FREE, PREMIUM, ULTIMATE)
- Finally, locate the feature that this Badge belongs to and hide it in the page, without breaking the page layouts
- Make a function that receives two parameters, tier (Saas and Self-Managed) and license (FREE, PREMIUM, ULTIMATE), and uses them to filter out the features using the code created before
- Make sure we can revert the filtering and show every feature on the page again, add a tier and license called
All
On part 2, my aim is to create the code for the function that will filter out the information, and on part 3 show how we can turn this function into a chrome extension
