Move away from OTP 18 and adopt rebar3_lint 0.3.0

[paulo-ferraz-oliveira]

I move away from OTP 18, but get back 19.1, 19.2, 20.1 and 21. 😄
In any case, if you're willing to accept this, it might solve what issues you faced.
Trying to support OTP 18.3 (in testing) is incompatible with rebar3 and the newest rebar3_lint, which I also update and fix here (I didn't set off to mix both these issues, but won't want to fix them separately).

Edit: maybe closes #99 and closes #100.

[seriyps]

I wonder if we can try to use erlang:${{ matrix.otp_vsn }}-alpine? But I think Erlang only supports alpine starting from OTP-20

[paulo-ferraz-oliveira]

Let me check that for you. Edit: I'm curious at the advantage of it, though.

[paulo-ferraz-oliveira]

Yup, 19.x not available as alpine. Everything else available as alpine.

[andreineculau]

I vote down this suggestion. I'm also curious to hear your pov @seriyps , but going ubuntu to debian already adds unnecessary friction that has little to do with Erlang (see minimum git version for github actions), and going debian to alpine could potentially add even more - if not now, later.

My pov is that obviously there might be reasons to deploy systems running on specific distros. Similarly, if you wanted to test software in different distros, you'd go for specific distros. But in this case, we're testing some Erlang sofware that we think has no distro-specific behaviour, so ideally I would test with the easiest distro to work with - Ubuntu.

@paulo-ferraz-oliveira you mentioned the setup-erlang action https://github.com/marketplace/actions/setup-erlang . A cursory read makes me assume that they download a "compiled" version (fast install times). Is that right? Did you try it out?

[paulo-ferraz-oliveira]

I've already tried it out, but IIRC I stumbled upon a more difficult version management (not all versions were available, for example). Want me to test it out here? I'm assuming you're looking for faster builds.

[andreineculau]

My reasoning is more:

• there has to be one canonical way for erlang repos to test in CI, specifically github actions.
• that canonical way should probably be based on Ubuntu, for reasons of keeping the bar low

Speed should rarely be a goal, but it can be a show stopper - like when I tried to use kerl, and it would build OTP for 10+ minutes.

Let's merge this PR as is, because it is an improvement over what we have. Thank you for that.

IFF you want, file another PR with setup-erlang. From the looks of it, it could be that canonical solution that I'm referring to, and if you have already implemented it for inaka's repos, all the better.

[andreineculau]

I went down the path of installing git@2.18 myself in fb3fb97 but I ended up with a longer build times https://github.com/for-GET/jesse/actions/runs/465881686

my deps were
apt-get install -y make libssl-dev libghc-zlib-dev libcurl4-gnutls-dev libexpat1-dev gettext unzip
based on https://linuxize.com/post/how-to-install-git-on-debian-9/#installing-git-from-a-source

I left some review items, but all in all yeah. Let's ditch OTP 18, and build git from source. Ideally the erlang docker images would up the git version 🤔

[paulo-ferraz-oliveira]

Ideally the erlang docker images would up the git version 🤔

One day I'm sure they will, but ideally so would they use the most recent rebar3 version (or at least one that wouldn't break the CI).

[paulo-ferraz-oliveira]

If the latest commit's CI tests pass, I guess this is good for merge (?)

[andreineculau]

THANK YOU!