I'd like to help with gnome shell extension smoke tests

Sri Ramkrishna had a comment on reddit about shell extension smoke test with gitlab ci agent

I would like to help with that but need some guidance. My first question is can someone write up in plain English some sort of a user story? How do you see it work? There’s a new merge to master in gnome shell. What should happen next?

1 Like

Most of that conversation is here - https://gitlab.gnome.org/World/ShellExtensions/extensions-rebooted/-/issues/1

and thank you for volunteeering!! I’m also working on some new onboarding concepts in regards to this.

So there are two things. One is release engineering - which is when a new gnome shell release happens and then we test the extensions against it as part of the release process. The idea then is to test all the extensions and find out which breaks and then setup a system to alert extension writers that their extension is broken and needs to be fixed as part of compliance to be listed on extensions.gnome.org. That isnt’ really in the works yet because we really need to focus on the infra.

The second and most active work now is build out of the infra to test extensions. That means we want to have a ci container that will run the stable version of gnome-shell and test the extension against it. Right now that testing is just a smoke test of ‘does it load’, but as we understand more we can start making it more intelligent - this is where community needs to jump in and help. I think building these tests might be a bit tricky. The other thing is that we want to automate reviews as much as possible.

The current status is that I have a container that can run gnome-shell (using distro version) and it can load and unload extensions headless. From here we need to:

  • build a docker container that will do the same thing (I’m using podman/buildah) and that will recreate everything I need to run gnome-shell. The tricky bits are being able to run dbus-session in the container and then finding a way to launch gnome-shell with it.
  • some thoughts on the architecture

This is a real fun project with a great payback and a time saving for GNOME. Really excited to work on it.

On the first bullet point. You have smoke tests in podman container working. And you would like to have docker container. Is that right? If this is right, what is the reason to move from podman to docker?

The reason I ask this is that I can run containers from images (built by podman) with docker. Both docker and podman implement the same spec.

If you already have podman to build an image, and both docker and podman can start a container from it, then I wonder why the transition is desired.

@sri I’ll get the gitlab agent work with the image you’ve build with buildah.

I’ll then go ahead and read up on gitlab ci and how to use the agent in gitlab.

I’ll then have more down to earth questions.

Sounds great… although I will need to replicate what I did. :slight_smile: So I’ll try to work on that so that you can build it using buildah and podman.

It shouldn’t be too hard since I"m using all distro version stuff. I’ll come up with the buildah script that replicates all the packaging and then send you what command I used. I’ll put it in the issue associated with building the image.

1 Like

@sri sure, happy to wait. Alternatively, if you could guide me on how to run GNOME headless - I could figure out the rest (bugging you and others from time to time about d-bus, where do we get extensions from etc) .

Awesome, thanks! It might take me a bit of work to produce it… I should probably try to publish my container somewhere so that it can be downloaded at the very least so you can decompose it.

1 Like

Do you use shared runners or do you build and deploy somewhere your own? In the latter case, where do you deploy your runners to?

I have updated the repo with my build script to build the container. Right now it isn’t what I want. The container works for the tests (it’s documented how to do it) but I need to fix how it runs. Mostly I think I need to copy the zip file to be tested and then create a systemd target that will run the test as a user.

I used podman because it seems to be the only container tech that seems to incorporate systemd properly versus the others (at least from searches).

Regarding your question about runners, I have not even gotten that far yet. GNOME has gitlab runners but I think they use docker. I could theoretically use my machine at home for that as needed or try to get work to cough up some runners as a community resource for everyone (that we can donate to the Linux Foundation)

I’ll have a look at your code this weekend. I’ll put my efforts on running tests the way you see best, with systemd target.