• Pl chevron_right

      Jordan Petridis: Goblins in your toolchain

      news.movim.eu / PlanetGnome • 10:05 • 2 minutes

    At the start of the month, Bilal gave us all a giant gift with Goblint . On the first week it was already impressive. Now it’s an invaluable tool for anyone that ever interfaced with GObject, glib or GTK. It will catch leaks, bugs, or even offer to auto fix and modernize your code to the modern paradigms we use. It’s one of those things that is going to save countless hours of debugging and more importantly, prevent the issues before they even get committed. Jonathan Blandford wrote about using it two days ago, and I suggest you read the post .

    Everyone is trying to use goblint, and we are all stumbling upon the same issues integrating it into our tooling. Initially, it was only able to produce Sarif reports, which GitLab still has behind a feature flag , in addition to only  be available in GitLab Enterprise Editions.

    I added support for GitLab’s Code Quality format which has some support in the non-proprietary Community Edition we use in the GNOME and Freedesktop.org instances. Sadly, almost everything nice is still only available in the enterprise editions, but at least there is this little Widget in the Merge Requests page.

    A screenshot of the linked Merge Request showcasing the Code Quality GitLab widget.

    Additionally, we now have CI templates for Goblint. One is adding a job to the existing gnomeos-basic-ci component we use everywhere. Simply go to your latest pipeline and look for the job .

    A screenshot of the linked job and its output log

    The report will also show up in Merge Requests that have been updated since yesterday.  The gnomeos-basic-ci has other goodies like sanitizers, static analyzers, test coverage, etc wired out of the box, so you should give it a try if you are not using it yet.

    If you do but don’t want the goblint job, you can disable it easily with inputs: goblint: "disabled" similar to all the other tools the component provides.

    include:
      - project: "GNOME/citemplates"
        file: "templates/default-rules.yml"
      - component: "gitlab.gnome.org/GNOME/citemplates/gnomeos-basic-ci@26.1"

    If you want only a goblint job, I’ve also added a standalone template that you can use. (Or copy-paste from it).

    include:
      - component: "gitlab.gnome.org/GNOME/citemplates/goblint@26.1"
        inputs:
          job-stage: "lint"

    In order for the Code Quality report to work, you will need to have a report uploaded from your target branch, so GitLab will have something to compare the one from the merge request with. The template rules will handle that for you, but keep it in mind.

    At this moment all the lints are warnings so the job will never be fatal. This is why we can enabled it by default without worrying about breaking pipelines for now. You can further configure its behavior to your needs, and error out if you want to, through the configuration file.

    min_glib_version = "2.76"
    
    [rules.g_declare_semicolon]
    level = "ignore"
    
    [rules.untranslated_string]
    level = "error"
    ignore = ["**/test-*.c"]

    It’s also very likely that we are going to add goblint and its LSP server to the GNOME SDK Flatpak runtime, along with GNOME OS, so it will always be available for use with tools like Builder and foundry.

    Enjoy