This pull request, when merged, will generate and upload an AppImage of each commit. It does so by bundling MyPaint, Python, and the required Python modules inside the AppImage.
That’s awesme! I’m glad to see more and more projects picking up AppImage!
I’ve been thinking maybe @CarVac’s Filmulator would be nice in an AppImage; It looks fairly light on the dependencies.
1 Like
Very interesting! I guess some of the improvements in the MyPaint appimage recipe could also be used for Gimp…
I will also try to port the automatic travis building to PhotoFlow as well, if I manage.
I might be wrong, but I guess that the dependency on Qt5 makes it difficult to compile it on older systems.
Very cool! Indeed it can be useful to have an AppImage of each continuous build, it can help in testing bleeding-edge versions. Especially when combined with binary delta updates.
Luckily this is no problem thanks to https://launchpad.net/~beineri/+archive/ubuntu/opt-qt57-trusty. The official Qt binaries from the Qt company are compiled with CentOS 6 and should also work for this purpose.
I have been working on a tool that should making AppImages from Qt applications especially easy:
2 Likes
That’s awesome! Thanks for your hard work.
@probono Your MyPaint example is a real gem!!! I’ve followed it during the last couple of days and now I have a working travis configuration for PhotoFlow that automatically builds a new AppImage each time there is a new commit pushed to the stable branch.
Next step will be to add automatic building of OSX and Windows versions (cross-compiled in the latter case).
Also, is there a way to send the appimage file to some persistent file storage, directly from within the travis shell script?
Thanks!!!
Check my example, I use transfer.sh to upload each build.
I’m doing it already… however, it is a temporary storage and one needs to look into the travis log to find out the exact link.
It would be nice to send the files to some permanent storage, where people can subscribe to be notified of updates. Or maybe where the AppImage itself could look for updates and notify the user… don’t know however if that would be possible with some free service. Any idea?
Digital Ocean sponsors a lot of free software stuff, and discourse is hosted there; are they sponsoring us @patdavid? If not, there are many other web hosts who sponsor, perhaps we can talk to them.
Did you mean to post this on the MyPaint topic?
Yes, @Carmelo_DrRaw is looking for storage for the travis-built appimages.
1 Like
I’d have to sit down and digest what the process workflow for this is, but we are hosted on digital ocean, and we have a full VPS running this forum - so we could technically find a way to make this work.
Ideally, though, I’d prefer to use the host for the main website instead, as the storage is (relatively) unlimited there. Unfortunately, I cannot create new accts on that machine with which to allow upload access easily. Doesn’t Travis allow you to hide something like an ssh key from the public logs, but to still use it as part of a final build process? I thought I saw something like that (at least on gitlab you can). If so, it’s possible to trigger an upload to the pixls.us/files area on successful build, I think?
[edit] - I’m also happy to investigate something like Amazon S3 storage for us to use if needed. Prices are around $0.03/GB right now. I could probably also offload image storage on discuss out to S3 at that point as well.
I’d also be happy to script a solution to pull down the builds to my file server, make a torrent, and upload the torrent somewhere, and seed it. I’ve got ~5TB unused space. That solution has that 90s warez feeling to it 
1 Like
90s was FTP servers and napster/edonkey. The torrents were in the 00s. And if you want to be up-to-date you should use a one click hoster I guess. 
1 Like
Hi Patrick, and thanks for the hosting offer!
As far as I could quickly read, there seem to be some ways to deploy files from Travis to DigitalOcean (see Travis CI deployments to DigitalOcean and Travis CI integration using git | DigitalOcean), however I have presently no time to dig into that further.
On the other hand, deploying from Travis to a GitHub release seems to be rather easy, so I think I will initially go for this solution.
At the moment I am almost at the stage of having automatic generation of AppImages and OSX .dmg packages via Travis, triggered by any commit to my stable branch. Apart from the practical advantage of not having to deal with the building and packaging process myself, there is also a security advantage: each build is performed inside a clean and virtualized environment, so the risk of distributing infected packages should be practically excluded…
…for tagged builds yes, but for untagged (continuous) builds? Probably need to code a simple uploader using the GitHub API
Check AppImageUpdate and this video:
With AppImageUpdate, the information travels with the software embedded inside the AppImage. So no repositories to manage, the AppImage knows how to update itself.
What is cool about this: Since this uses binary delta updates, you only have to download the bytes that actually have changed from build to build.
Right now there are two transport mechanisms implemented, zsync over plain http(s) and zsync on Bintray. If Bintray is not an option for you, we could also implement zsync on GitHub Releases, I suppose.
I am pretty close to just getting some Amazon S3 storage. If I do, then this should be a pretty easy solution for many things (not just your builds).
1 Like