-
Notifications
You must be signed in to change notification settings - Fork 315
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
base: main
Are you sure you want to change the base?
Habitat on Apple Darwin #9469
Conversation
- 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]>
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]>
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]>
Signed-off-by: Johny Jose <[email protected]>
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]>
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]>
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]>
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]>
✅ Deploy Preview for chef-habitat ready!
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]>
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]>
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. |
Signed-off-by: Phani Sajja <[email protected]>
@mwrock @agadgil-progress @jasonheath This PR is ready for review i believe. Pls review it this week if possible. |
@rahulgoel1 : The status still shows as @sajjaphani : Can you squash this PR into a set of few related commits before marking it ready for review? |
@rahulgoel1 / @sajjaphani : Is there a Jira ticket that describes what exactly is being done in this ticket? Is it CHEF-17583? |
There was a problem hiding this 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
- I have mainly reviewed the
plan-build-*
shell scripts. I believe there is a lot of code duplication inplan-build-linux
,plan-build-darwin
andplan-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 asTODO
in these files at-least. - 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.
- 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(|_| { |
There was a problem hiding this comment.
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) |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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) |
There was a problem hiding this comment.
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.
Signed-off-by: Phani Sajja <[email protected]>
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 |
@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. |
There is a small issue when running with 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
Also, trying to build some of the "core" packages is not successful, but this is mainly due to the error $ 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/ |
Trying to build the |
Signed-off-by: Phani Sajja <[email protected]>
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 Once that is done, build and release packages with the latest code to acceptance (unstable). After that we should add test cases using the Finally when everything is ready - make those packages available in Does that make sense? |
I tried to get this working on macOS Sonoma - here is the mileage -
|
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
On the But build of May be I am missing something, but the bootstrap process should not require the remote builder (whatever is required for |
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):