I have already started blogging about Ansible; in particular, I have shown how to develop and test an Ansible role with Molecule and Docker, also on Gitpod.

This blog post will describe my Ansible role for installing the GNOME desktop environment with several programs and configurations. As for the other roles I’ve blogged about, this one is tested with Molecule and Docker and can be developed with Gitpod (see the linked posts above). In particular, it is tested in Arch, Ubuntu, and Fedora.

This role is for my personal installation and configuration and is not meant to be reusable.

The role can be found here: https://github.com/LorenzoBettini/my_gnome_role.

The role assumes that at least the basic GNOME DE is already installed in the Linux distribution. The role then installs several programs I’m using on a daily basis and performs a few configurations (it also installs a few extensions I use).

At the time of writing, the role has the following directory structure, which is standard for Ansible roles tested with Molecule.

The role has a few requirements, listed in “requirements.yml”:

These requirements must also be present in playbooks using this role; my playbooks (which I’ll write about in future articles) have such dependencies in the requirements.

The main file “tasks/main.yml” is as follows:

This shows a few debug information about the current Linux distribution. Indeed, the whole role has conditional tasks and variables depending on the current Linux distribution.

The file installs a few programs, mainly Gnome programs, but also other programs I’m using in GNOME.

The “vars/main.yml” only defines a few default variables used above:

As seen above, the package for “python psutils” has a different name in Arch, and it is overridden.

For Arch, we have to install a few additional packages, which are not required in the other distributions (file “gnome-arch.yml”):

For the Guake dropdown terminal, we install it (see the corresponding YAML file).

The file “gnome-templates.yml” creates the template for “New File”, which, otherwise, would not be available in recent versions of GNOME, at least in the distributions I’m using.

For the search engine GNOME Tracker, I performed a few configurations concerning the exclusion mechanisms. This is done by using the Community “dconf” module:

This also ensures that possibly previous versions of Tracker are not installed. Moreover, while I use Tracker to quickly look for files (e.g., with the GNOME Activities search bar), I don’t want to use “Tracker extract”, which also indexes file contents. For indexing file contents, I prefer “Recoll”, which is installed and configured in my dedicated playbooks for specific Linux distributions (I’ll blog about them in the future).

Then, the file “gnome-configurations.yml” configures a few aspects (the comments should be self-documented), including some custom keyboard shortcuts (including the one for Guake, which, in Wayland, must be set explicitly as a GNOME shortcut):

Then, by using the “petermosmans.customize-gnome” role (see the requirements file above), I install a few GNOME extensions, which are specified by their identifiers (these can be found on the GNOME extensions website). I leave a few of them commented out, since I don’t use them anymore, but I might need them in the future):

Then, we have the files for installing and configuring Flatpak, which I use only to install the GNOME Extension manager:

I installed them system-wide (the “user” option is commented out).

Concerning Molecule, I have several scenarios. As I said, I tested this role in Arch, Ubuntu, and Fedora, so I have a scenario for each operating system. The “default” scenario is Arch, which nowadays is my daily driver.

For Ubuntu, we have a “prepare.yml” file:

The reason why is explained in my previous posts on Ansible and Molecule.

By default, I test that “flatpak” is installed. (see the default variables above: by default, Flatpak is installed)

But I also have a scenario (in Arch) where I run the role without Flatpak:

For this scenario, the “verify.yml” verifies Flatpak is not installed:

Of course, this is tested on GitHub Actions and can be developed directly on the web IDE Gitpod.

I hope you find this post useful for inspiration on how to use Ansible to automatize your Linux installations 🙂