Toggle automatic uploads for PRs

[tresf]

1. Open a pull request scroll down and look for the latest commit, click the dot.
   

2. Click the platform that you can test on:
   

3. Click "Scroll to the end" of log:
   

4. Wait a minute for it to catch up and then find the https://transfer.sh portion...
   You might have to unclick the scroll button again.
   

---

Original description:

Steps to add a testable, downloadable build artifact for every PR against LMMS.

• @PhysSong to sync stable-1.2 back into master to pull in any .AppImage improvements (e.g. Add libjack.so.0 fallback logic for AppImages #3958, Add Carla Support to AppImage #4026, d0194e6, f15acb8)
• @Umcaruje /@tresf to communicate with power-users (e.g. @StakeoutPunch, @SecondFlight) how to fetch the binaries, possibly get a list of testers, post on Discord, etc.
• @lukas-w @tresf transfer the following build types:
  • win32
  • win64
  • mac10.11
  • linux64

... and wishful thinking...

Click here: https://travis-ci.org/LMMS/lmms/builds/312544160

* Provide a webhook to update the bug report with the latest transfer.sh URL.

I'm shamelessly assigning to @lukas-w as I think he's already started this but I may end up tackling this myself if he's too busy as well as @PhysSong for the branch syncing although that's already on the todo list.

[lukas-w]

I'm shamelessly assigning to @lukas-w as I think he's already started this

Haven't started any work on this. You may be thinking of my CircleCI PR #3921, which adds automatic uploading of AppImages to CircleCI's servers.

[tresf]

You may be thinking of my CircleCI PR #3921

Probably. I'll tackle it then. Work is happening on the transfer branch here: https://travis-ci.org/tresf/lmms/branches

[tresf]

@musikBear, here's a 32-bit bit build of the master branch from Travis-CI. I hope you don't mind me using you as a guinea pig.

Click here: https://travis-ci.org/LMMS/lmms/builds/312544160

Click (e.g.) the win32 job here:

Click "Follow log"

Wait a minute for it to catch up and then find the https://transfer.sh portion...
You'll have to un-click the scroll button to go back up.

(Please pardon the poor versioning information, I have to iron that out still).

Others please feel free to test this out. If you think it's warranted, we can write-up a wiki on it.

[tresf]

Bad news, transfer.sh has posted on Twitter that it's dying. Switching to file.io. https://twitter.com/dutchcoders/status/913835197237465089

[tresf]

file.io is working great. Updated PR via 06b2516, updated instructions. Testing appreciated.

[musikBear]

hope you don't mind me using you as a guinea pig.

@tresf not at all, i will come back with results
__
I could build fine through
https://travis-ci.org/LMMS/lmms/builds/312544160
The created binary was fetched with no problems
Installation went perfect.

ReleaseVersion: 1.2 RC 4.6493 win32 winXPsp3
Basic function test

• installs
• opens
• preserve settings
• load older project
• create project from template
• replay
• saves
• exports (new as loops too with correct % done (bug fix))

correctly & with no problems.
One thing went through my mind:
Is it 'safe' to open this access for everyone?
Eg is everything 'secure' for malicious attacks? ( I know, i am just being me 🤡

[tresf]

Eg is everything 'secure' for malicious attacks?

Separate topic, really but I'll bite...

Security of temporary uploads

This depends on the security of the site we're uploading to. If that site is compromised, the build would be as well. Since Windows injections are the most common, the biggest attack surface would be the win64 executables as they represent about 80% of our downloads.

Some items that mitigate the attack surface: 1. The files are only stored for two weeks. 2. The files are generally only used by developers and testers. 3. The files are created and hosted on a non-Windows machine, so the germination environment is non-native which reduces exposure.

Feel free to reach out to transfer.sh on your own to get some baseline security practices if it will make you feel better about it all.

Functionality test

Thanks. The main purpose of this is to make sure you can locate and run an installer from a PR to aid with testing. My thought process is that if you and several others know how to fetch the build artifacts, it will be a standard part of unit testing. i.e. The functionality testing is not needed at this time, but thanks for the sanity check. 👍

On a side note, I'm still struggling to find a permanent home for these artifacts. I've switched back to transfer.sh now as they've brought their system back online but I've received no information via Twitter in regards to how long the service will be around for.

[tresf]

All builds are uploading, @musikBear was able to locate and run the build, so the last item is the branch sync. I'm tempted to just merge #4041 as-is so we can start taking advantage of this now for new features like groove beats, track recording, etc @PhysSong /@liushuyu thoughts?

[musikBear]

@tresf Thanks for clarification in respect to security 👍
I can add that it only took seconds to build online, and the procedure was simple
(i btw have a copy of the whole log. Just let me know if i should upload it)

[PhysSong]

@PhysSong to sync stable-1.2 back into master to pull in any .AppImage improvements (e.g. #3958, #4026, d0194e6, f15acb8)

@tresf I can't sync changes in WeakJack in #4026 because it is a submodule in master. Maybe need a PR against upstream?

[tresf]

@PhysSong done via x42/weakjack#7. I think you can technically reference the commit ID of my PR now although I always get mixed results leveraging a non-default branch.

[tresf]

@PhysSong x42/weakjack#7 has been merged.

[PhysSong]

@tresf Branch sync is done.

[tresf]

@PhysSong thanks! Merged #4041. All PRs against master will now be uploaded to transfer.sh for Windows, Mac and Linux. :)