Multi distro build test

[rhdxmr]

I come up with this PR when I ran into the build failure of #131. Because I
tried building RedBPF only under my Pop OS, I could not recognize the build failures
derived from other distros.

And also by Dockerfile-alpine-20210212 this PR suggests the solution of #130.

[rsdy]

I think it would be better to make these part of the CI process. I'm currently trying to break free of CircleCI on the foniod/build-images#1 PR, and use that to build the base builder images for the 3 main distros.

As soon as that works, we should move these Dockerfiles over, and extend the CI here with these builds. What do you think?

[rhdxmr]

I am not familiar with CircleCI yet, so I have a question about it.
Can I use circleCI readily in localhost to test multi distro build in person?
If some build failure happen, it is required to run build test manually, repeatedly, readily.

[rsdy]

In theory this exists, but I could never get it working reliably. It comes with a lot of limitations, and I don't think we can actually use their local build tool for RedBPF.

CircleCI CLI has some docs on usage if you would like to try regardless.

My usual workflow involves triggering an actual CI run in the cloud, and working through it on a branch. Not the most fun, but I think you have a lot of scaffolding to play with at this stage. Do let me know if you need help, though, and I can probably take a look!

[rhdxmr]

@rsdy
I added a github action to build redbpf on ubuntu-20.04 and fedora-rawhide containers which are made by foniod/build-images.
What about using github action instead of circle CI?
I think it is better because foniod/build-images uses it already and it provides better integration with github.

[rsdy]

I think it's a good direction! GitHub Actions also looks like a better long-term option than CircleCI, so happy to go down this route!

[rsdy]

Do we want to override the containers' kernels with whatever we get from GitHub? I feel like this can potentially make it harder to build for a larger range of kernels.

Going forward, I think it might be helpful to think about building for many different kernel versions to see what we can/cannot support.

Just a suggestion, though, I think it's not a straightforward thing so will be a process to get there.

[rhdxmr]

I fixed it not to mount volumes of kernel headers and changed to specify KERNEL_VERSION environment variable for containers.

[rhdxmr]

I fixed workflow to make kernel version not to be hard coded because base image from foniod/build-images can change its kernel headers.

[rhdxmr]

I could not add build test for ubuntu-18.04.
Because I ran into compile error.

   Compiling bpf-sys v1.3.0 (/build/bpf-sys)
error: No suitable version of LLVM was found system-wide or pointed
       to by LLVM_SYS_110_PREFIX.

       Consider using `llvmenv` to compile an appropriate copy of LLVM, and
       refer to the llvm-sys documentation for more information.

       llvm-sys: https://crates.io/crates/llvm-sys
       llvmenv: https://crates.io/crates/llvmenv
   --> /usr/local/cargo/registry/src/github.com-1ecc6299db9ec823/llvm-sys-110.0.1/src/lib.rs:486:1
    |
486 | / std::compile_error!(concat!(
487 | |     "No suitable version of LLVM was found system-wide or pointed
488 | |        to by LLVM_SYS_",
489 | |     env!("CARGO_PKG_VERSION_MAJOR"),
...   |
496 | |        llvmenv: https://crates.io/crates/llvmenv"
497 | | ));
    | |___^

error: aborting due to previous error

error: could not compile `llvm-sys`

To learn more, run the command again with --verbose.
warning: build failed, waiting for other jobs to finish...
error: build failed

And the version of included kernel header is 4.15.0-142-generic. It is too old version.

[rsdy]

If you remove the CIrcleCI builds, I can merge this and move on from here. I know how to fix the LLVM_SYS issues, but we also need to upgrade to LLVM 12 as the latest Rust compiler already uses that.

[rhdxmr]

CircleCI config is deleted.
Thanks,