Auto-publishing Linux 32/64 + OSX binaries to GitHub

[wilzbach]

(See also: #1367)

Linux 32 and 64-bit + OSX already work. Only Windows is missing, but there isn't any script which currently uses LATEST anyhow (+ my Windows knowledge is quite limited).

It already works on my fork:

• https://github.com/wilzbach/dub/releases/tag/v1.7.17
• https://github.com/wilzbach/dub/blob/gh-pages/LATEST (and thus: http://wilzbach.github.io/dub/LATEST)

Notes:

1. I disabled the test stage for tag deployments, because there are still many random and spurious failures and if someone deliberately tags a new version, the deployment should succeed and not fail due to some tests depending on a host to be online.

2. I used build stages, s.t. LATEST is only updated after all three deployment jobs have run successfully. This avoids the case where LATEST is updated by the Linux job and the OSX job takes a few seconds/minutes longer or even fails.

3. Lastly, the normal PR/master is unaffected (see e.g. https://travis-ci.org/wilzbach/dub/builds/339909754)
   If wanted we can also always run the deploy stage, but just skip the actual deployment step. Travis supports this out of the box.

Resources:

• https://docs.travis-ci.com/user/build-stages/
• https://docs.travis-ci.com/user/conditional-builds-stages-jobs/

[dlang-bot]

Thanks for your pull request, @wilzbach!

[wilzbach]

I wasn't sure how the DUB binaries are currently generated, but we probably want to use LDC and it's amazing optimizer.
In a next step, LTO + PGO should/could follow.

BTW for reference:

Compiler	Size
DMD	17M
LDC	13M
GDC	19M

(though of course size isn't all, but I don't have the time to run a benchmark at the moment, but I strongly assume that ldc is our best choice)

[s-ludwig]

Regarding binary size, I'd keep debug info, though, because it often considerably speeds up the diagnostic process in case of bugs. BTW, does LDC generate stack traces with names for uncaught exceptions? I remember that this didn't use to be the case.

[wilzbach]

Regarding binary size, I'd keep debug info, though, because it often considerably speeds up the diagnostic process in case of bugs.

Sure, build.sh already adds -g and I never argued against ;-)

BTW, does LDC generate stack traces with names for uncaught exceptions? I remember that this didn't use to be the case.

https://run.dlang.io/is/zsSvOA (nope it does't)

If that's a deal breaker, we can also switch to dmd. It's a very simple change in the travis.yml config after all.

[ibuclaw]

Shared or static linking? :-)

[wilzbach]

With static linking on Linux (at least for DMD + LDC).

[s-ludwig]

Apart from the stack trace issue this looks good to go. I'd suggest that on Windows, for now I'll just add the curl command to upload the binaries to my own CI deployment step. We'd have to install NSIS on AppVeyor otherwise and I'd like to spent my time in a more productive way currently than remote debugging on AppVeyor for something that is not currently relevant (LATEST + Windows).

[wilzbach]

Apart from the stack trace issue this looks good to go.

Changed to dmd for now then, s.t. this doesn't block this PR.
I thought that the dub was already compiled with ldc :/

[wilzbach]

@s-ludwig FYI: I created @dlang-dub-bot

and added its GH_REPO_TOKEN to the Travis config. We can't use the @dlang-bot because it already runs into sometimes into API rate limits..

Ideally with the upcoming master-stable branch off an automatic releases should be triggered :)

[s-ludwig]

Good to know, I'll use that in my script, too, then. I made a quick test, but unfortunately didn't have curl installed. I'll look into that tomorrow.

[s-ludwig]

Took me way longer than expected to fight the Windows command processor (should have just installed bash), but it appears to be working now.

[wilzbach]

Cool. Thanks!

It looks like 1.7.2. didn't include the new Travis changes yet (https://github.com/dlang/dub/blob/v1.7.2/.travis.yml), so I have fingers crossed that everything works when master gets merged into stable soon ...

[MartinNowak]

I'm wondering whether this second release channel is actually such a good idea?

At least extracting the dub binaries from the official dmd archives seems like a better approach than to rebuild different binaries.
We could easily integrate this into the release.sh script, prolly not much more than tar and 7z.
Do we really still need a Windows exe installer? Seems like a problematic idea, since it inherently conflicts with the dmd/ldc installations.

Furthermore the use-case for updating dub separately of the compiler seems rather small. Let's reconsider to drop this release channel altogether.

[s-ludwig]

Furthermore the use-case for updating dub separately of the compiler seems rather small.

Always tying the two together just increases the general friction even more for projects that need to support a larger range of compiler versions. It should be stressed that we are talking about something that produces very little additional work in the long run, but it can potentially affect a large number of people and projects in a positive way (or otherwise in a negative way like the annoying Travis-CI change that removed the independent DUB installation).

Integrating into the general release process definitely makes sense, though.