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

Update macOS SDK to 14 #239

Merged
merged 1 commit into from
Jan 19, 2024
Merged

Update macOS SDK to 14 #239

merged 1 commit into from
Jan 19, 2024

Conversation

gitperr
Copy link
Contributor

@gitperr gitperr commented Dec 29, 2023

@SuperQ previously stated that we need to update the xcode stuff in golang-builder image:
prometheus/node_exporter#2539 (comment)

So, I've attempted to do that. More below:

What I've done

  • Read & understood Xcode license terms
  • Extracted and used macOS SDK 14
  • As I don't have access to PROM_OSX_SDK_URL secret, I used my local copy of macOS SDK (Not committed to repo) >> This will fail the CircleCI pipeline
  • Bumped JOBS to 4 to make compilation faster
  • Created new golang-builder image with updated macOS SDK, didn't change tagging (resulting tag was quay.io/prometheus/golang-builder:1.21.5-main-master) (Not yet committed to quay.io!)

Questions

  1. Why don't we commit the SDK tar files to the repo?
  2. How can I test the new image with CircleCI?
  3. What are your thoughts about the license terms? (see my notes below)

Notes

Xcode license agreement says

You may use the macOS SDKs to test and develop application and other software;

and

Except as otherwise expressly set forth in Section 2.2.B., You may not distribute any Applications
developed using the Apple SDKs (excluding the macOS SDK) absent entering into a separate written
agreement with Apple

My interpretation is that we are able to develop, and distribute using macOS SDK.
But, the catch was right at the start:

THIS SOFTWARE IS AUTHORIZED ONLY FOR EXECUTION ON AN APPLE-BRANDED PRODUCT
RUNNING MACOS. ANY OTHER DOWNLOAD OR USE OF THIS SOFTWARE IS NOT AUTHORIZED
AND IS IN BREACH OF THIS AGREEMENT

In this case, I feel like we should stay in the safe side and build it on macOS machine, as CircleCI already offers those.

To do (My plan)

Feel free to comment!

  • With help of maintainer, commit the SDK tar under the secret PROM_OSX_SDK_URL, or change the way SDK is injected into the docker image
  • With help of maintainer, get CircleCI stuff sorted, maybe add a mac runner to be on the safe side
  • Test the new image on CircleCI
  • Clean up (Put JOBS back to what it was, and put PROM_OSX_SDK_URL stuff back to what it was if we won't change the injection method)

Feel free to add more comments and info as you see fit.
Thanks!

@SuperQ
Copy link
Member

SuperQ commented Jan 17, 2024

I think the issue is that we can't build a cross-compiling package that will work in our docker image without uploading and using the SDK as we're currently using it.

@gitperr gitperr force-pushed the master branch 2 times, most recently from 493ba15 to 4d5646e Compare January 18, 2024 16:21
Copy link
Member

@SuperQ SuperQ left a comment

Choose a reason for hiding this comment

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

Nice, looks good. Just need to also update 1.20.

Signed-off-by: Alper Polat <[email protected]>

Revert back to using secret URL

Signed-off-by: Alper Polat <[email protected]>

Add && back

Signed-off-by: Alper Polat <[email protected]>

Remove useless copy

Signed-off-by: Alper Polat <[email protected]>

Put JOBS back to 2

Signed-off-by: Alper Polat <[email protected]>

Update 1.20 as well

Signed-off-by: Alper Polat <[email protected]>
@gitperr
Copy link
Contributor Author

gitperr commented Jan 18, 2024

Updated 1.20 too and squashed.

@SuperQ SuperQ merged commit 80439d9 into prometheus:master Jan 19, 2024
4 checks passed
@SuperQ
Copy link
Member

SuperQ commented Jan 19, 2024

I tested this manually on my system and it seems to build and run fine. I don't have an arm64 mac to test with.

@gitperr
Copy link
Contributor Author

gitperr commented Jan 20, 2024

I could not make it work on my arm64 mac:

 alperpolat@Alpers-Air ~/..../node_exporter  master  file node-darwin
node-darwin: Mach-O 64-bit executable arm64
 alperpolat@Alpers-Air ~/..../node_exporter  master  sw_vers
ProductName: macOS
ProductVersion: 14.2.1
BuildVersion: 23C71
 alperpolat@Alpers-Air ~/..../node_exporter  master  ./node-darwin
zsh: killed     ./node-darwin
 alperpolat@Alpers-Air ~/..../node_exporter  master  ./node-darwin --version
zsh: killed     ./node-darwin --version

# We will need to run the codesign utility on it 
 alperpolat@Alpers-Air ~/..../node_exporter  master  codesign -vvvv node-darwin
node-darwin: invalid signature (code or signature have been modified)
In architecture: arm64

# So I run the next command to sign it (gives no output):
codesign -s - node-darwin

# Then check again how it looks:
 alperpolat@Alpers-Air ~/..../node_exporter  master  codesign -vvvv node-darwin
node-darwin: valid on disk
node-darwin: satisfies its Designated Requirement

# and it runs afterwards properly
alperpolat@Alpers-Air ~/..../node_exporter  master  ./node-darwin --version
node_exporter, version 1.7.0 (branch: master, revision: e22174ca8e47993dbc8c3aab8c2e6906f06926b5)
  build user:       root@3b884409dfd1
  build date:       20240119-22:13:43
  go version:       go1.21.6
  platform:         darwin/arm64
  tags:             netgo osusergo static_build

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.

2 participants