-
Notifications
You must be signed in to change notification settings - Fork 15
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
Enable macos packaging and tests #44
Conversation
I just merged a big re-organization, sorry about that. You'll probably need to rebase this significantly. |
I was already building it on top of the branch of the merged PR, so it shouldn't be too hard. |
Can you enable aarch64 as well? |
@@ -0,0 +1,13 @@ | |||
# OS TRIPLET ALLOW_FAIL ARCH_ROOTFS MAKE_FLAGS TIMEOUT ROOTFS_TAG ROOTFS_HASH |
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.
No need for ARCH_ROOTFS
, ROOTFS_TAG
or ROOTFS_HASH
here. Those columns can be deleted.
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 ARCH_ROOTFS is how the script currently knows what arch is running. Just need to make it so it gets the info from the triplet or the ARCH variable.
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.
ARCH_ROOTFS
should only be used with sandbox; any other uses of the arch should parse it out from the triplet, which is done by calc_version_envs.sh
Yeah, I was very very confused, I was like wow, aarch64 is building very nice, then it was on the x86 builder 😄 . Do you want to add an specific ARCH columns, or just keep ARCH_ROOTFS, rename it or somerhing? |
ARCH_ROOTFS is supposed to refer to the architecture of the rootfs image that we're downloading, which isn't happening on these machines, so I'd rather name it just |
Isn't there an ARCH variable already? That |
Yes, but that variable is not available at YAML parse time, sadly. |
Fair enough, I guess adding to the .arches file won't hurt. Not sure why the aarch64 build didn't work. I donwloaded it and it gave me broken dylib errors 🤔 . Will try to see if current master actually works on the m1. |
The aarch64 tester is failing because the binaries are not codesigned. I've updated our testing fork of Julia to include the latest fixes from Mosè for that, so the next build you push should have more luck there. This is looking pretty good! I think we're ready to embed the codesigning toolchain, so I went ahead and did that for you. Let's have the workflow be:
|
That sounds great to me, thanks :). I will see if later tonight or maybe tomorrow I can get to that. |
The x86_64 machine is pretty old: |
echo "--- Ad-hoc sign for testing" | ||
MACHO_FILES=$(find "$${JULIA_INSTALL_DIR}" -type f -perm -0111 | cut -d: -f1) | ||
for f in ${MACHO_FILES}; do | ||
codesign -s - --option=runtime -vvv --timestamp --deep --force "${f}" |
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.
If possible, let's make use of https://github.com/JuliaLang/julia/blob/master/contrib/codesign.sh here
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.
Do we have access to it directly from the julia repo or do I add it to utilities?
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.
You'll have access to it from the Julia repo, but we probabily need to update our fork.
Why does adhoc signing not work here 🤔 why does apple make this so more difficult than it should be. |
@staticfloat @gbaraldi Now that Buildkite has a built-in matrix feature, what do you guys think of trying it out for this PR? |
We may be able to do that, as long as we don't have to use the matrix attributes in a plugin. (E.g. we only interpolate the values within the Gabriel; are you blocked on anything, or just busy? I want to get this PR moving again, and just want to understand where things stand. |
Yeah my week was a bit busier than i expected, however today I will work on it some. |
@gbaraldi Anything that would have been |
55c160d
to
08297ea
Compare
66ff398
to
52dda3c
Compare
Alright! I think the config here is good. Now we just need to figure out how to fix the Pkg problems without shunting them to node 1. |
Pkg problems are worked around as of JuliaLang/julia#44828 So we can merge this when ready. |
52dda3c
to
2085542
Compare
2085542
to
e197260
Compare
The main idea is to merge our `build`, `test` and `upload` steps into single, shared `.sh` files that get included from our `.yml` files. We try to walk the line correctly between storing Julia-related content (such as `julia.icns`) in the Julia repository, while storing the build rules (such as `build_dmg.sh`) within this repository.
e197260
to
3880043
Compare
🥳 It's purple and green 🥳 thousands of segfaults notwithstanding. |
Nice work, Gabriel! |
Depends on #42. I have no idea if this is working or not. This is a rebase on this PR but with a similar structure to what is on #42