Mabl is a SaaS software testing product that includes an Electron-based desktop application for local authoring and execution of browser and API tests. It’s kind of like an IDE/debugger for tests. Currently we distribute a .deb package but are hoping to be able to distribute our app via the Snap Store to reach a wider audience and for the benefit of automatic updates. We’re currently packaging our Snap with electron-builder and uploading it to the Snap Store via the snapcore/action-publish Github action.
Although I’m still new to the Snap world, I believe our app requires classic confinement for a few reasons, but the main one concerns the way our app integrates with the browser on the user’s machine. The mabl app launches a Chromium instance for creating and executing tests, but it does not ship with its own Chromium (today anyway). Instead it finds and uses whatever Chromium is installed on the user’s system. We have to get direct access to the binary rather than using xdg-open because we need full control over the arguments that are passed to Chromium on startup (e.g. to enable debug protocols, etc.). So far I have not found a way to make this work with strict confinement.
Note that we have two separate snaps that we are publishing: mabl-app and mabl-app-dev. I’m sure you’re wondering why we do not use channels for this instead, so I’ll try to explain that. The mabl-app-dev snap represents a completely separate build of our app with a different icon and configuration that connects to the mabl development environment rather than our production environment, and it also enables additional debugging information to be collected. This build is only intended to be used by engineers and QA within mabl, and we will likely restrict this snap to collaborators only. The mabl-app snap is our main build for end users that connects to our production environment.
Please let me know if you have any questions or if there is any other information I can provide. I’m also happy to supply testing accounts if you need to try out the app for yourself.
Below is a screenshot showing the electron app on the right and the browser from the user’s machine open in debug mode on the left with our training interface in the middle. Thanks very much for your consideration.
Just checking in to find out whether there is any additional information I can provide to help the @reviewers reach an informed decision on this. Here’s a quick summary of the request:
mabl is an IDE and debug tool for authoring and executing tests against websites and web APIs.
The mabl app needs to execute arbitrary commands on the user’s system. For example, we need to be able to launch Chrome with certain debug flags and settings that are specific to the user’s environment in order to create and edit tests.
We are publishing two separate snaps that both need classic confinement:
mabl-app-dev is an internal build for QA purposes which is configured to connect to our internal development environment/APIs and enables us to collect more verbose debugging information
Both of these snaps have revisions that have been uploaded to Snapcraft but were auto-rejected due to classic confinement. Please let me know if any further information is required to process this request. Thank you!
How can mabl be used as an IDE? Does it require access any specific file/folder from the host? Does it perform any type of let’s say compilation? I ask to understand which specific accesses are not available under strict confinement that prevents mabl to properly work. Also, any specific technical reason around not shipping chromium into mabl?
Hi @emitorino, thanks for the reply. The main reason for requiring classic mode at this time is that in order to author, execute, and debug browser tests with the mabl app, we need to be able to do the following:
Find the user’s Chrome/Chromium binary by looking in one of several possible locations on the user’s system (/usr, /opt, etc.)
Execute the found Chrome/Chromium binary with arbitrary flags to enable remote debugging and apply other user-specific settings
Upload arbitrary test artifacts from the user’s machine as directed by the user
I think there’s a likely path for us to transition away from classic mode this year. As you mentioned, we are actively exploring whether we can bundle Chromium within the app itself. This will give us better consistency across our installs and eliminate a bit of complexity as well. We just need to de-risk a few customer security concerns as some of our customers are sensitive to non-approved browser installs. If we can get past those issues and bundle Chromium then I think it will eliminate the main blocker for strict confinement. So it’s our goal to get there and something that we’re actively pursuing.
From what I can tell at https://www.mabl.com/product and the description you have provided, since mabl needs to execute arbitrary commands then it is not possible for it to be a strictly confined snap. As it is a debug tool, then it would fit within the debug or possibly IDE category defined in Process for reviewing classic confinement snaps for classic confinement.
As such, the requirements for classic confinement are understood.
@advocacy could you please perform publisher vetting?
Hi @Igor. Is there something I can help with here regarding the publisher vetting? Did you reach out to our support address? If so I can reach out to that team to make sure they know the context here.
Hi @Igor. Our support team has looked for emails containing “snap” and “canonical” in their inbox but has not been able to find the one that you sent. Could you please let me know what email address it would have come from and also confirm the email address you sent it to? You can DM me if you’d like to keep it out of the main thread. Thanks!
