[Audacity-devel] Audacity AppImage continuous builds on Travis CI

[probono]

Dear Audacity developers,

wouldn't it be useful if each continuous build from Travis CI would be
available for download and testing on local machines? We can now do
that.

This pull request, when merged, will generate and upload an AppImage
of each commit:
https://github.com/audacity/audacity/pull/172

It does so by bundling Audacity and its core dependencies which cannot
be expected to be part of each target system (Linux distribution)
inside the AppImage.

The URL of the AppImage can be found near the bottom of each Travis CI
build log. Of course you can change this to use the GitHub Releases
mechanism for hosting the binaries instead.

For example, the resulting AppImage from commit df3c21d can be downloaded from
https://transfer.sh/Tdm8O/audacity-travis1993-glibc2.15-x86-64.appimage
as indicated in
https://travis-ci.org/audacity/audacity/builds/175318699#L6577
Of course, we could also use something like GitHub Releases for more
permanent storage.

To run this, just download the AppImage file from the link above, set
the executable bit (chmod +x), and run. No installation needed, no
root needed, no system libraries touched. If you are done testing,
just delete the one AppImage file. The AppImage is expected to run on
most Linux distributions. Some fine-tuning might still be required, so
I'd welcome your testing and feedback!

For more information on AppImage, see http://appimage.org/

Regards,
probono

[James Crook]

Simon,

I don't see a license.txt file in the Git repo. Wikipedia says MIT
license and that's what I see in the sources when I've looked into
files. Could you add a license.txt file to your repo or make it clearer
in the readme what license the AppImageKit binaries are released under?

In the pull request I'm wary of the:
wget -q https://github.com/probonopd/AppImages/raw/master/functions.sh
-O ./functions.sh
and...
wget -c
https://github.com/probonopd/AppImageKit/releases/download/continuous/appimagetool-x86_64.AppImage

These mean that what we 'release' could contain almost anything.
I like the general idea, but if Audacity is to do it:
1) Team as a whole would need to agree to it.
2) It would need some tweaking so that e.g.
a) we pull from https://github.com/audacity/AppImageKit
b) we review appimagekit changes carefully before updating our clone
of it.
c) we don't release every Travis build, just selected ones.

If we released with AppImageKit, the release would include compiled
wxWidgets and FFmpeg, wouldn't it? So we would need to build those too
and pull them in from somewhere.
A possible approach is that we would have a
https://github.com/audacity/AudacityAppImage project that we would push
to, to trigger a Travis AppImage build, rather than do it on every
Travis build.

--James.

Post by probono
Dear Audacity developers,
wouldn't it be useful if each continuous build from Travis CI would be
available for download and testing on local machines? We can now do
that.
This pull request, when merged, will generate and upload an AppImage
https://github.com/audacity/audacity/pull/172
It does so by bundling Audacity and its core dependencies which cannot
be expected to be part of each target system (Linux distribution)
inside the AppImage.
The URL of the AppImage can be found near the bottom of each Travis CI
build log. Of course you can change this to use the GitHub Releases
mechanism for hosting the binaries instead.
For example, the resulting AppImage from commit df3c21d can be downloaded from
https://transfer.sh/Tdm8O/audacity-travis1993-glibc2.15-x86-64.appimage
as indicated in
https://travis-ci.org/audacity/audacity/builds/175318699#L6577
Of course, we could also use something like GitHub Releases for more
permanent storage.
To run this, just download the AppImage file from the link above, set
the executable bit (chmod +x), and run. No installation needed, no
root needed, no system libraries touched. If you are done testing,
just delete the one AppImage file. The AppImage is expected to run on
most Linux distributions. Some fine-tuning might still be required, so
I'd welcome your testing and feedback!
For more information on AppImage, see http://appimage.org/
Regards,
probono
------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel

[probono]

Post by James Crook
I don't see a license.txt file in the Git repo. Wikipedia says MIT
license and that's what I see in the sources when I've looked into
files. Could you add a license.txt file to your repo or make it clearer
in the readme what license the AppImageKit binaries are released under?

Thanks James for the hint, was missing from the currently active branch, added.

Post by James Crook
wget -q https://github.com/probonopd/AppImages/raw/master/functions.sh
-O ./functions.sh

You could simply mirror the functions.sh script and the things it
fetches. The only reason I implemented it this way is so that you can
automatically benefit from bugfixes. But I understand your reasoning.

Post by James Crook
1) Team as a whole would need to agree to it.

Sure. If there are objections against it, I'd like to hear them so we
can find a solution.

Post by James Crook
2) It would need some tweaking so that e.g.
a) we pull from https://github.com/audacity/AppImageKit
b) we review appimagekit changes carefully before updating our clone
of it.

Sure.

Post by James Crook
c) we don't release every Travis build, just selected ones.

Why? Isn't it the point of continuous integration to have build
artifacts available for each push that can be tested? Imho testing
should not only be automated, but there should also be the possibility
to do manual tests.

Post by James Crook
If we released with AppImageKit, the release would include compiled
wxWidgets and FFmpeg, wouldn't it? So we would need to build those too
and pull them in from somewhere.

As it stands now, they are pulled in from the Travis CI build system.
Seems to work.

Post by James Crook
A possible approach is that we would have a
https://github.com/audacity/AudacityAppImage project that we would push
to, to trigger a Travis AppImage build, rather than do it on every
Travis build.

Yes, that would also be an option. But it would mean (some) more manual work.

[Gale Andrews]

If we go for this I would expect there to be a build for each commit,
or at least one a day.


Gale

Post by probono

Post by James Crook
I don't see a license.txt file in the Git repo. Wikipedia says MIT
license and that's what I see in the sources when I've looked into
files. Could you add a license.txt file to your repo or make it clearer
in the readme what license the AppImageKit binaries are released under?

Thanks James for the hint, was missing from the currently active branch, added.

Post by James Crook
wget -q https://github.com/probonopd/AppImages/raw/master/functions.sh
-O ./functions.sh

You could simply mirror the functions.sh script and the things it
fetches. The only reason I implemented it this way is so that you can
automatically benefit from bugfixes. But I understand your reasoning.

Post by James Crook
1) Team as a whole would need to agree to it.

Sure. If there are objections against it, I'd like to hear them so we
can find a solution.

Post by James Crook
2) It would need some tweaking so that e.g.
a) we pull from https://github.com/audacity/AppImageKit
b) we review appimagekit changes carefully before updating our clone
of it.

Sure.

Post by James Crook
c) we don't release every Travis build, just selected ones.

Why? Isn't it the point of continuous integration to have build
artifacts available for each push that can be tested? Imho testing
should not only be automated, but there should also be the possibility
to do manual tests.

Post by James Crook
If we released with AppImageKit, the release would include compiled
wxWidgets and FFmpeg, wouldn't it? So we would need to build those too
and pull them in from somewhere.

As it stands now, they are pulled in from the Travis CI build system.
Seems to work.

Post by James Crook
A possible approach is that we would have a
https://github.com/audacity/AudacityAppImage project that we would push
to, to trigger a Travis AppImage build, rather than do it on every
Travis build.

Yes, that would also be an option. But it would mean (some) more manual work.
------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel