Add GHA workflow for Linux builds

[gaborcsardi]

The goal of this is to be able to check the build on various Linux distros quickly, since it seems non-trivial to work out the exact packages needed.

It also fixes the build on the tested distros, using the stock packages from the distro.

Issues:

• There is a lot of repetition in the Dockerfiles and the workflow as well, which we might DRY out at some point.
• No caching. Which is bad for the Fedora + R-devel run, because it builds dependencies from source, including arrow, which is really slow.
• It does not run any tests with the built package currently.
• This probably breaks the build with hand-compiled grpc, as suggested by the README, I'll fix that.

In any case, while not ideal, it is useful as a workflow that you can trigger manually, I think. We can improve it later, as needed.

[meztez]

@gaborcsardi Well this project has not felt the love in a long time! I'm trying this right away.

[gaborcsardi]

Haha, wait a bit, still fixing things up, hence the draft. :)

[gaborcsardi]

Some questions and comments.

While this PR focuses on Linux, it might break things on macOS and/or Windows. IMO not a big issue, because the macOS and Windows builds do not work very well currently, anyway, and I'll submit separate PRs for those soon. (Managed to build static libs for macOS already: https://github.com/gaborcsardi/homebrew-cran/releases)

Is there a particular Linux distro you use for bigrquerystorage, or you think is important to support well? I'll add those to the build matrix.

More soon.

[gaborcsardi]

@meztez Another question. Is it important to use the latest grpc (& co.) (for you and/or for users) or we can use the stock packages in the distros?

[gaborcsardi]

@meztez Assuming the Fedora-38 build [1] works as well (works for me locally), this is ready for review.

[1] https://github.com/gaborcsardi/bigrquerystorage/actions/runs/7034431076/job/19142470084

[meztez]

Some questions and comments.

While this PR focuses on Linux, it might break things on macOS and/or Windows. IMO not a big issue, because the macOS and Windows builds do not work very well currently, anyway, and I'll submit separate PRs for those soon. (Managed to build static libs for macOS already: https://github.com/gaborcsardi/homebrew-cran/releases)

Is there a particular Linux distro you use for bigrquerystorage, or you think is important to support well? I'll add those to the build matrix.

More soon.

I use Ubuntu LTS, usually the latest (right now, jammy).

Windows builds but does not work, it fail in winsocket and I spent too much time in dbg and gave up.

[gaborcsardi]

@meztez Sorry, I was commenting/editing comments, so you missed some:

Another question. Is it important to use the latest grpc (& co.) (for you and/or for users) or we can use the stock packages in the distros?

This PR probably breaks the build with hand-compiled grpc, as suggested by the README, I'll fix that.

[meztez]

@gaborcsardi fixed the README, I'd rather use the distro packages if they are available. Tested it, works fine. Windows still broken.

[meztez]

Some questions and comments.

While this PR focuses on Linux, it might break things on macOS and/or Windows. IMO not a big issue, because the macOS and Windows builds do not work very well currently, anyway, and I'll submit separate PRs for those soon. (Managed to build static libs for macOS already: https://github.com/gaborcsardi/homebrew-cran/releases)

Is there a particular Linux distro you use for bigrquerystorage, or you think is important to support well? I'll add those to the build matrix.

More soon.

You are taking on quite an endeavour there.
#18 (comment)

[gaborcsardi]

You are taking on quite an endeavour there.

Well, for CRAN we'll need to compile grpc statically, if that's possible at all. (Should be, because I did it for macOS, although haven't tested that it actually works.) My hope is that if we compile it statically, with the compiler(s) CRAN uses, then we don't run into this issue. We'll see. I'll start that soon, let's finish macOS first.