Build Debian package

[Daniel15]

What's the problem this PR addresses?
Adds a GitHub Action to build the Debian and RPM packages for Yarn.

TODO:

• Test .deb package on Ubuntu
• Test .deb package on Debian
• Test .rpm package on CentOS
• Add .cmd wrapper to tarball for Windows
• Set version number of trunk builds to date, like Yarn v1 does
• Fix RC version number so Lintian is happy with it

How did you fix it?
A lot of the logic has been copied the from Yarn v1 repo, with a few changes made to allow it to run using GitHub Actions.

Which packages would need a new release (if any)?
N/A

Have you run yarn version prerelease in those packages?
N/A

[Daniel15]

The idea here was that instead of building Yarn multiple times, it's instead just built once, and other jobs retrieve the built artifacts. However, this also means that the Debian package build can't start until all the unit and integration tests finish running. I might just deal with it building multiple times.

[arcanis]

I think it's fine to rebuild it, as they are run in parallel anyway. Maybe later we could find a solution to only build it once for all the workflows (not only the jobs in one workflow).

[Daniel15]

Cool, will do.

[Daniel15]

Mostly the same as https://github.com/yarnpkg/yarn/blob/master/Dockerfile.dev

[Daniel15]

Most of this is the same as https://github.com/yarnpkg/yarn/blob/master/scripts/build-deb.sh

[Daniel15]

Copied directly from yarn v1. Need to double check if all of these are still needed - A lot of them were due to node_modules junk.

[arcanis]

Were those tags meant to describe the yarn package itself, or what it installed? We didn't have a node_modules in the deb file, right? 🤔

[Daniel15]

@arcanis - lintian is a linter for Debian packages, and this is a list of the ignored lint rules for the resulting package. These overrides were added before we included a bundle in the Debian package, so many are outdated now.

[arcanis]

I wasn't entirely sure where to put this. I'd like it to run for every build so we catch any breakages, but it also needs to run for releases.

Is that necessary? What could cause it to break? Since we're now using mostly integration tests, the CLI itself is fairly well tested and there's little risks we would accidentally break the rpm.

What I would suggest would be to move it inside of its own workflow file, and use a trigger to only build it on PRs that touch the relevant files (scripts/actions/build-deb & its dependent workflows ), using the paths modifier. Then in the release workflow we would add a new step that would also run it and put it within the artifacts directory.

[Daniel15]

What I would suggest would be to move it inside of its own workflow file, and use a trigger to only build it on PRs that touch the relevant files (scripts/actions/build-deb & its dependent workflows ), using the paths modifier.

This is a really good idea. Will do when I get a chance!

I was thinking of the nightly builds too, but now they can actually be scheduled nightly builds (max one per day) rather than just all master builds, and we can build all the packages only for the scheduled builds rather than for every PR and master commit.

[arcanis]

I was thinking of the nightly builds too, but now they can actually be scheduled nightly builds (max one per day) rather than just all master builds, and we can build all the packages only for the scheduled builds rather than for every PR and master commit.

Note that nightly builds are a bit less important on the v2 (at least for the main bundle) because we will have yarn set version from sources, which will clone the repository and build a bundle fresh from master to use in a local project.

[Daniel15]

I think this is ready for review now, I just need to figure out how to make it run as part of the release. I've tested the package on Ubuntu 18.04 (current LTS), Ubuntu 19.04 (latest release), and CentOS 7.