Add FreeBSD Support

[hut8]

Summary

Adds support for FreeBSD

Release notes

lifecycle will now build on FreeBSD.

---

Related

#1087 - this is rather old, had a lot of conflicts, and probably needs extensive CI tweaking. So I chose to start fresh, but used some parts of this as a starting point, so credit to @quantumsheep

Surprisingly there is no issue that mentions FreeBSD but there should be 😄

---

Context

I need this because the fly.io CLI depends on this package and I want to be able to run it from FreeBSD.

superfly/flyctl#712

[codecov]

Codecov Report

Attention: 3 lines in your changes are missing coverage. Please review.

Comparison is base (3c8876c) 63.99% compared to head (ecf97c6) 63.97%.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1271      +/-   ##
==========================================
- Coverage   63.99%   63.97%   -0.02%     
==========================================
  Files         100      100              
  Lines        6909     6913       +4     
==========================================
+ Hits         4421     4422       +1     
- Misses       2081     2083       +2     
- Partials      407      408       +1     

Flag	Coverage Δ
os_linux	63.44% <40.00%> (-0.02%)	⬇️
os_windows	56.68% <0.00%> (-0.03%)	⬇️
unit	63.44% <40.00%> (-0.02%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

[hut8]

What's up with the ARM64 test failing? And I could use some guidance about the local_handler_test failure - I realized I'm actually a bit confused about how this communicates with a local docker engine (docker in docker) -- i.e., what's listening on /var/run/docker.sock in Linux? Is that the same docker that's running the CI container? In FreeBSD, when I'm running docker, I do it in a separate virtual machine under bhyve and use TCP to connect the two.

[natalieparellano]

@hut8 thanks for this!

What's up with the ARM64 test failing?

That seems to be a flake. I can re-kick the CI.

In FreeBSD, when I'm running docker, I do it in a separate virtual machine under bhyve and use TCP to connect the two.

Here is where we initialize the docker connection in the lifecycle:

lifecycle/priv/docker.go

Line 16 in 3c8876c

func DockerClient() (*client.Client, error) {

I think it should just work if you've set DOCKER_HOST in the lifecycle's environment. LMK if you have already tried that. We do more complicated initialization in pack (see here and here) but so far we haven't needed that in the lifecycle.

[patmaddox]

@hut8 Have you attempted to build flyctl with this branch? I've tried adding replace github.com/buildpacks/lifecycle => github.com/hut8/lifecycle ecf97c6bc078 to flyctl go.mod and here's what I get:

$ PATH=/usr/local/go121/bin:$PATH go get
...
github.com/buildpacks/lifecycle: cannot find module providing package github.com/buildpacks/lifecycle

$ PATH=/usr/local/go121/bin:$PATH mod tidy
...
github.com/buildpacks/lifecycle: module github.com/buildpacks/lifecycle@latest found (v0.18.4, replaced by github.com/hut8/lifecycle@v0.0.0-20240117010513-ecf97c6bc078), but does not contain package github.com/buildpacks/lifecycle

So I'm not sure how to override this dependency with your branch to try building flyctl.

[hut8]

@patmaddox sorry, I'm not sure! I didn't actually get flyctl to build, because I was stuck on the test failures in CI that I couldn't really explain, and now I have loads of dayjob work :)
I checked the go.mod file and it definitely should contain that module, though. I didn't replace any modules with my github username in place of buildpacks.