Rename the plugin so it makes more sense (just change the filename and the value of plugin:.Add back in the architectures from your original snapcraft.yaml, so the build service knows which ones you’re actually interested in.You could probably remove some of the plugs for your snap ( password-manager-service, avahi, cups, etc).Ensure the apps: section reflects your specific application, the app should probably be named the same as your package name, and the command would need to be pointed at your own binary in the snap.Keep the cleanup part (it makes the snap smaller!), but if you change the name of your source, ensure the after: variable is kept up to date.Remove adopt-info and replace it with version: git.On the snapcraft.yaml side, you would probably want to: You’d then also customise the _build_commands() to work for your particular snap, but from what I see, it isn’t actually that far off from what you’ve already done. If you take a look into the joplin.py plugin, adopting this for your own work, you’d remove the _apply_patches() from the build commands, because you aren’t using them. And finally, gui/ contains the desktop icon and desktop metadata that actually puts your snap on the desktop so users can click on it. plugins/joplin.py contains the equivilent of the override-build you used above, except by defining it as a custom plugin you can make the snapcraft.yaml slightly easier to understand by hiding some of the complexity elsewhere. Snapcraft.yaml contains all your usual metadata, including the apps: stanza needed to make the snap actually runnable. This is an Electron project I make a snap for myself, and hopefully it’ll make a good example for you. You’d need to actually set up your app: stanza to make it work, along with any plugs, and probably the Gnome extensions, but this should let Snapcraft do it’s work from start to finish, letting you make proper use of the build environment while offering more control over the end result than Electron Build raw would.Īnd because you’re aiming for 3 architectures, it’s probably worth saying the name of the linux-unpacked folder varies per architecture too, so personally I actually use mv *unpacked just to catch them anyway. Mv dist/linux-unpacked $SNAPCRAFT_PART_INSTALL/myApp -r If you find a folder (e.g, dist/linux-unpacked), it actually contains everything that’s needed, you just need to put it into the right place where snapcraft expects it, so you’d add to your override something like mkdir $SNAPCRAFT_PART_INSTALL/myApp -p But I’d take a look around in your build folder because it might already exist. I’m not sure whether you can select that as a target by itself, or whether it’s a byproduct of selecting AppImages as a target.
Not working with Electron directly, I know that it’s possible to make Electron Build generate a folder that’s simply unpacked. The build system would have no reason to believe a valid snap was generated at all in this instance, because it didn’t complete the usual lifecycle. This solves some niche but troublesome problems, such as the odd issues people have with font rendering not working in certain setups.īut certainly you’ll need to make some changes, because the Snapcraft Build System (as in, the runners provided in the cloud to do the CI for you) will more than likely just abort and not work if it recieves the exit 1 command. However I do often recommend people use Snapcraft anyway, because it makes it easier to do certain changes, for example, you can more easily swap to Core20 and use the desktop extensions with a raw snapcraft.yaml file, than you could with Electron Build last time I checked.
Using Electron Build like this is an antipattern, it’s designed to be run independently of Snapcraft, in the host environment, where it would make a snap itself, including for foreign CPU architectures.
Is there some way to get rid of that dummy package? I suspect it’s going to cause problems when doing automated builds in the cloud. However, after running snapcraft command there is also a second dummy boxy-svg_3.73.0_amd64.snap package (produced by snapcraft itself rather than by electron-builder). The entire task of snap package creation is delegated to electron-builder tool which produces boxy-svg-amd64.snap package.
#BOXY SVG PLUGIN PROFESSIONAL#
For beginners as well as for professional web designers and web developers. Summary: Scalable Vector Graphics (SVG) editor.ĭescription: "Boxy SVG project goal is to create the best tool for editing SVG files. I’m using the following snapcraft.yaml config file to build a snap package for my app in a confined environment: name: boxy-svg
0 kommentar(er)
