lifecycle
lifecycle copied to clipboard
Add FreeBSD Support
Summary
Adds support for FreeBSD
Release notes
lifecycle will now build on FreeBSD.
Related
https://github.com/buildpacks/lifecycle/pull/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.
https://github.com/superfly/flyctl/issues/712
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%) |
:arrow_down: |
| os_windows | 56.68% <0.00%> (-0.03%) |
:arrow_down: |
| unit | 63.44% <40.00%> (-0.02%) |
:arrow_down: |
Flags with carried forward coverage won't be shown. Click here to find out more.
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.
@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: https://github.com/buildpacks/lifecycle/blob/3c8876ce042837896e76d2d31e8c18c48a8aa738/priv/docker.go#L16
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.
@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/[email protected]), 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.
@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.