Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Habitat on Apple Darwin #9469

Open
wants to merge 55 commits into
base: main
Choose a base branch
from
Open

Habitat on Apple Darwin #9469

wants to merge 55 commits into from

Conversation

sajjaphani
Copy link
Contributor

@sajjaphani sajjaphani commented Nov 12, 2024

This PR includes some initial work for enabling macOS aarch64 support for Habitat. It provides the necessary environment for bootstrapping core packages on macOS with the help of the sandbox-exec tool.

What’s coming next (separate PRs):

  • Plan files for Habitat components (hab/sup/studio, etc.)
  • Pipeline setup
  • Add/update existing tests to work on macOS

- support -N flag for hab pkg build
- fixes bug in hab-plan-build due to change of 'stat' binary due
   to build

Signed-off-by: Johny Jose <[email protected]>
Signed-off-by: Johny Jose <[email protected]>
Signed-off-by: Johny Jose <[email protected]>
Signed-off-by: Johny Jose <[email protected]>
- adds studio prompt
- adds support for various environment variables
- adds support for .studiorc
- adds support for loading secrets into studio

Signed-off-by: Johny Jose <[email protected]>
- adds tmp directories to sandbox
- adds various binaries provided by xcode to sandbox exclusion
- adds SUDO_USER inside the studio
- reworks do_strip to work correctly on macos in hab-plan-build

Signed-off-by: Johny Jose <[email protected]>
Signed-off-by: Johny Jose <[email protected]>
Signed-off-by: Johny Jose <[email protected]>
Signed-off-by: Johny Jose <[email protected]>
Copy link

netlify bot commented Nov 12, 2024

Deploy Preview for chef-habitat ready!

Name Link
🔨 Latest commit fc91ba8
🔍 Latest deploy log https://app.netlify.com/sites/chef-habitat/deploys/67b8919b6eda1d00081979ed
😎 Deploy Preview https://deploy-preview-9469--chef-habitat.netlify.app
📱 Preview on mobile
Toggle QR Code...

QR Code

Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify site configuration.

Signed-off-by: Phani Sajja <[email protected]>
Signed-off-by: Phani Sajja <[email protected]>
Signed-off-by: Phani Sajja <[email protected]>
Signed-off-by: Phani Sajja <[email protected]>
Signed-off-by: Phani Sajja <[email protected]>
Signed-off-by: Phani Sajja <[email protected]>
Signed-off-by: Phani Sajja <[email protected]>
Signed-off-by: Phani Sajja <[email protected]>
Signed-off-by: Phani Sajja <[email protected]>
@jasonheath
Copy link
Contributor

jasonheath commented Feb 4, 2025

Starting to look at this I feel like the verify pipeline should be updated to run expeditor/scripts/verify/run_studio_test.sh for macOS the same as happens now for both Windows and Linux. Is there something that prevents parity here? And the follow question is if that does make sense are there other places where the verify pipeline should be updated?

Beyond that, I can't run the code as I have an x86 mac but nothing stands out looking through the code changes. Looks like shellcheck and shfmt could be run on some of the affected files but those might be better as smaller focused shllcheck/shfmt commits/PRs.

@rahulgoel1
Copy link
Contributor

@mwrock @agadgil-progress @jasonheath This PR is ready for review i believe. Pls review it this week if possible.

@agadgil-progress
Copy link
Contributor

@rahulgoel1 : The status still shows as Draft PR.

@sajjaphani : Can you squash this PR into a set of few related commits before marking it ready for review?

@agadgil-progress
Copy link
Contributor

@rahulgoel1 / @sajjaphani : Is there a Jira ticket that describes what exactly is being done in this ticket? Is it CHEF-17583?

Copy link
Contributor

@agadgil-progress agadgil-progress left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it's a good idea to rebase this against latest main and squash commits into a few relevant ones otherwise the git log will be cluttered with too many trivial commit messages. - the build this was rebased against is kind of old

  1. I have mainly reviewed the plan-build-* shell scripts. I believe there is a lot of code duplication in plan-build-linux, plan-build-darwin and plan-build-darwin-internal which can be pulled out in a common functionality. May be we want to take that up in a subsequent work but better to mark that as TODO in these files at-least.
  2. Also the documentation to work with this code exists in a separate repo, unless that is by design - that is if we want to keep all MacOS work private, it's a better idea to pull the documentation locally.
  3. Some minor comments/changes otherwise.

This is more like a first pass of review for early feedback. I will continue looking at components/studio/* files for further details. I am also trying to work with this code locally and see the mileage. Initial quick tests looked okay.

// Verify the certificate data
let cert_data =
fs::read(&src).unwrap_or_else(|_| panic!("Failed to read SSL_CERT_FILE at {}", src));
pem::parse_many(cert_data).unwrap_or_else(|_| {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This validation is not MacOS specific and would be applicable to Linux as well. Right? Is there any specific failure that is MacOS specific?

u)
bldrUrl="${OPTARG}"
;;
b)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

how is it different from channel argument above?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We cannot use the same channel to pull the specific hab package, in this case, from the aarch64-darwin-sonoma channel.

# # Internals
if ((BASH_VERSINFO[0] < 5)); then
echo "The habitat plan build script requires bash version 5.0 or later to be available in the environment PATH, current bash version is ${BASH_VERSINFO[0]}.${BASH_VERSINFO[1]}"
return 1
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

exit here?

@@ -0,0 +1,2825 @@
#!/usr/bin/env bash
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A very high level comment - there is too much of code that is inside hab-plan-build-{darwin|darwin-internal|linux} that is duplicated. I believe at some point of time it's a good idea to separate the internal functions and its own script similar to (shared / public). Else this is going to be a maintenance problem.

*) continue;;
esac
done
case "$pkg_target" in
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why this check is required in the hab-plan-build-linux.sh? It's a bit confusing.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This check is required until we have a sandbox-based studio for macOS.

@@ -0,0 +1,174 @@
(version 1)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I do not understand much about the sandbox-exec utility, so I am just marking it as viewed.

@agadgil-progress
Copy link
Contributor

Starting to look at this I feel like the verify pipeline should be updated to run expeditor/scripts/verify/run_studio_test.sh for macOS the same as happens now for both Windows and Linux. Is there something that prevents parity here? And the follow question is if that does make sense are there other places where the verify pipeline should be updated?

I agree. One challenge that I had while originally reviewing this code is - what is expected to work with this PR from the point of view of supporting MacOS. Looks like with this PR the studio should work and then there should be a verify pipeline for that - that works (I quickly tested test/test.sh which is linux specific as it uses busybox and that doesn't work for MacOS). Unless this PR explicitly calls out what should work and what should not work - it won't be possible to say whether expected functionality is working.

@sajjaphani
Copy link
Contributor Author

@jasonheath / @agadgil-progress Regarding the tests on macOS, the existing tests will not work. Currently, we do not have a standard set of Habitat packages for macOS in our repository. We will address that in a separate PR. Once those are added, we can start looking into the tests.

@sajjaphani sajjaphani marked this pull request as ready for review February 21, 2025 09:22
@agadgil-progress
Copy link
Contributor

There is a small issue when running with HAB_STUDIO_BINARY environment variable set -

Get the following error -

/Users/agadgil/Chef/habitat/components/studio/bin/hab-studio-darwin.sh: line 368: studio_binary_libexec_path: unbound variable

This can be fixed by adding following line to function set_libexec_path()

studio_binary_libexec_path=$libexec_path 

Also, trying to build some of the "core" packages is not successful, but this is mainly due to the error core/clang not found on the builder (which is not present in the acceptance builder on unstable or aarch64-darwin-sonoma

$ HAB_BLDR_CHANNEL=unstable HAB_BLDR_URL=https://bldr.acceptance.habitat.sh HAB_STUDIO_BACKLINE_PKG=core/hab-backline/1.6.1208 HAB_STUDIO_BINARY=/Users/agadgil/Chef/habitat/components/studio/bin/hab-studio-darwin.sh RUST_LOG=debug sudo -E hab studio build packages/applications/version-management/git/

@agadgil-progress
Copy link
Contributor

Trying to build the core package locally (as that is a reasonable way of testing the hab-studio), faced problems with a few packages, so not following that path coreutils build failure with latest clang similarly sed build failure with latest clang (available with core-packages-internal)

@agadgil-progress
Copy link
Contributor

@jasonheath / @agadgil-progress Regarding the tests on macOS, the existing tests will not work. Currently, we do not have a standard set of Habitat packages for macOS in our repository. We will address that in a separate PR. Once those are added, we can start looking into the tests.

Yes - agreed! I believe the correct course of action to be - to first get a working set of core packages and refer to the commits from this branch to build the core packages (locally using hab-auto-build) and then merge this into master - so that we know the studio from this works. Currently we do not have a good way of making sure the studio from this works. (Tried this with HAB_STUDIO_BINARY env variables, but builds fail due to missing core packages.)

Once that is done, build and release packages with the latest code to acceptance (unstable).

After that we should add test cases using the CI_BUILDER_CHANNEL override.

Finally when everything is ready - make those packages available in stable, base-xxxx as appropriate.

Does that make sense?

@agadgil-progress
Copy link
Contributor

I tried to get this working on macOS Sonoma - here is the mileage -

  1. The install script works fine (needs sudo)
  2. I am trying to build a set of core packages locally (as remote clang etc. packages are not available). For that I had to perform few additional installations - brew install coreutils, brew install bash, brew install gnu-tar, brew install wget , brew install protobuf, brew install xz. (we need to document this somewhere).
  3. While trying to build core-packages-internal locally (because no remote packages are available), I am facing error clang not found - while compiling some of the packages, clearly both clang and core/clang are install and can be invoked, but the do_build functions of some of the packages are not able to find it.

@sajjaphani
Copy link
Contributor Author

I tried to get this working on macOS Sonoma - here is the mileage -

  1. The install script works fine (needs sudo)
  2. I am trying to build a set of core packages locally (as remote clang etc. packages are not available). For that I had to perform few additional installations - brew install coreutils, brew install bash, brew install gnu-tar, brew install wget , brew install protobuf, brew install xz. (we need to document this somewhere).
  3. While trying to build core-packages-internal locally (because no remote packages are available), I am facing error clang not found - while compiling some of the packages, clearly both clang and core/clang are install and can be invoked, but the do_build functions of some of the packages are not able to find it.

What do you mean by remote packages not being available? They are present in the acceptance environment. You need to set the URL and channel appropriately to download the remote packages.

The command hab pkg install core/clang --url <BLDR_URL> --channel is failing?

The primary purpose of this PR is to bootstrap macOS plans. Are you able to bootstrap the plans?

@agadgil-progress
Copy link
Contributor

I tried to get this working on macOS Sonoma - here is the mileage -

  1. The install script works fine (needs sudo)
  2. I am trying to build a set of core packages locally (as remote clang etc. packages are not available). For that I had to perform few additional installations - brew install coreutils, brew install bash, brew install gnu-tar, brew install wget , brew install protobuf, brew install xz. (we need to document this somewhere).
  3. While trying to build core-packages-internal locally (because no remote packages are available), I am facing error clang not found - while compiling some of the packages, clearly both clang and core/clang are install and can be invoked, but the do_build functions of some of the packages are not able to find it.

What do you mean by remote packages not being available? They are present in the acceptance environment. You need to set the URL and channel appropriately to download the remote packages.

The command hab pkg install core/clang --url <BLDR_URL> --channel is failing?

The primary purpose of this PR is to bootstrap macOS plans. Are you able to bootstrap the plans?

This is the actual command I ran

$ sudo -E hab-auto-build build -m git 

On the core-packages-internal and macOS-plans branch. I have modified the plan.sh of the hab-* plans to point to the latest commit on this branch, so that we know the local habitat is built using the latest code.

But build of perl and bzip2 etc. some of the packages fails - because it fails to find the c compiler. The core/clang package is install (can do hab pkg exec core/clang clang). FWIW also installed brew install gcc (gcc here simply points to clang).

May be I am missing something, but the bootstrap process should not require the remote builder (whatever is required for install.sh works fine, because I can use that hab binary).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants