Generate AppImage for each git push on Travis CI#777
Conversation
|
Here is the URL to the AppImage built by this PR: https://travis-ci.org/Subsurface-divelog/subsurface/builds/297709527#L4165 |
|
Once #773 is merged, can be removed. |
|
Very strange, but I think this PR is not responsible for the 1 check failing? |
|
The tests use a single, shared resource (basically, a test account on our cloud storage infrastructure). So sometimes it happens that two people run the tests at the same time and just manage to step on each other. It's rare enough that I never bothered to fix it :-) |
|
So this includes the stuff that I did to speed up testing - until I have QtWebKit figured out this makes sense, but I'll need to remember to undo that to make sure we test all the patterns we want to test in our builds. |
Be sure to also upload the |
|
You're ahead of me - I haven't even LOOKED at this... |
That's |
|
No, it's Travis / Qt / dependencies stuff. But yes, I get your point, this isn't really about creating an AppImage, instead it's about having the right content FOR the AppImage :-) |
|
I may need your help once I have this all assembled the way I want it to then get the release right :-) |
|
Always happy to be tagged! Looking forward to seeing "continuous" on GitHub Releases, along with a zsync file :-) |
|
Quite a difference, going from 300 lines of code to just one fifth :-) |
|
I'll celebrate if I can generate fully functional AppImages again. I think I'm getting closer, though :-) |
|
If I understand correctly what you are doing with the uploadtool you are creating a 'fake' tag continuous and you create a release for that tag every time something is pushed... |
|
Well, for that it's much easier and you won't even need uploadtool: |
|
Woot - I have a fully functional AppImage (on Ubuntu - still have the OpenSSL problems on Arch). |
|
On Nov 5, 2017, at 2:52 PM, probonopd ***@***.***> wrote:
Once I have that figured out I'll look into creating 'releases' here and using your uploadtool.
Thanks @probonopd <https://github.com/probonopd>
Be sure to also upload the *.AppImage.zsync file.' which will enable delta binary updates with AppImageUpdate <https://github.com/AppImage/AppImageUpdate>.
OK, HELP. Which `.zsync` file? I don' t think I see that.
Also, is it normal that the build log doesn't include the running of the `uploadtool`?
|
Bear with me, we need to change something on our end. Will let you know when done.
It should and it does, at the end of https://travis-ci.org/Subsurface-divelog/subsurface/builds/297815003 (the JSON stuff) |
3 participants
Describe the pull request:
Pull request long description:
This PR, when merged, will compile this application on Travis CI upon each
git push, and upload an AppImage to a temporary download URL on transfer.sh (available for 14 days). The download URL is toward the end of each Travis CI build log of each build (see below for how to set up automatic uploading to your GitHub Releases page).For this to work, you need to enable Travis CI for your repository as described here prior to merging this, if you haven't already done so.
Please note: Instead of storing AppImage builds temporarily for 14 days each on transfer.sh, you could use GitHub Releases to store the binaries permanently. This way, they would be visible on the Releases page of your project. This is what I recommend. See https://docs.travis-ci.com/user/deployment/releases/. If you want to do this for continuous builds, also see https://github.com/probonopd/uploadtool.
If you would like to see only one entry for the Pull Request in your project's history, then please enable this GitHub functionality on your repo. It allows you to squash (combine) the commits when merging.
If you have questions, AppImage developers are on #AppImage on irc.freenode.net.
Changes made:
Related issues:
Closes #769
Additional information:
A build can be tested at https://transfer.sh/YWxH0/Subsurface-git.21ac633-x86_64.AppImage
Mentions:
@dirkhh