The i386 CI releases were still using x86_64 platforms for building the
output binaries, as a result the produced binaries did not work properly
on i386 systems.
The maximum time of 50 minutes was exceeded when Alacritty tries to build
for all Linux platforms, this was because it was effectively compiling
Alacritty from scratch four times.
By making use of the previous build artifacts, it's possible to cut this
down to two compiles using the `--no-build` option of `cargo-deb`.
The manpage was incorrectly zipped up with the `-z` option, which
doesn't exist and created a 0-size file. Since Github does not accept
0-size files, this lead to the complete release deployment failing.
Changing this to use the `-c` option should fix this problem by creating
a proper non-zero size gzip file.
The windows tagged builds currently fail some tests since the
winpty-agent.exe is inside the release directory instead of the debug
directory with tagged builds.
This release introduces some config to automatically build deploy a
binaries on the github release page using travis. The build only happens
when a commit is tagged and it uses the stable version of rust.
The main travis sections (install/script/before_deploy) have been
moved out of the .travis.yml to make it easier to read, maintain and
extend the different steps of the CI process.
Since checking for the Rust version in CI is enough to know if clippy
should be used or not, the environment variable `CLIPPY` has also been
removed, which further allowed simplifying the CI process.
Besides the executables, some auxillary files are now also published as
part of a release when they have changed since the last tagged Alacritty
release. This should make it clear for returning users when a new
version of a specific auxillary file is required.
Instead of using the 14.04 image which travis provides by default, an
18.04 docker image is used to build the output binaries for Linux.
This affects both the .deb and the .tar.gz binary.
The advantage of this is that while binaries compiled on 14.04, do not
work on 18.04, it does work the other way around. The generated .tar.gz
binary has been tested on 18.04, Debian, Fedora and Archlinux and all
systems were able to run it without any warnings or errors.
Christian Duerr