Skip to content

Add native build to CI and MUSL build #2490

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

Merged
merged 3 commits into from
Jun 11, 2025
Merged

Add native build to CI and MUSL build #2490

merged 3 commits into from
Jun 11, 2025

Conversation

Quinn-With-Two-Ns
Copy link
Contributor

@Quinn-With-Two-Ns Quinn-With-Two-Ns commented Apr 23, 2025

Add native build to CI and MUSL build

closes #2402

@Quinn-With-Two-Ns Quinn-With-Two-Ns changed the title Add native build to CI Add native build to CI and MUSL build Apr 25, 2025
@Quinn-With-Two-Ns Quinn-With-Two-Ns marked this pull request as ready for review April 25, 2025 15:16
@Quinn-With-Two-Ns Quinn-With-Two-Ns requested a review from a team as a code owner April 25, 2025 15:16
@@ -188,3 +188,9 @@ jobs:

- name: Run copyright and code format checks
run: ./gradlew --no-daemon checkLicenseMain checkLicenses spotlessCheck

build_native_images:
Copy link
Member

Choose a reason for hiding this comment

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

Is it by intention that we are building native images for every CI run now or is this leftover from testing? If it is by intention, I would usually be concerned with unnecessarily using storage for all of these images, though I see we only retain for one day, but I wonder if it's even worth that vs just a workflow call option to not upload the artifacts.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes, I do want to build as part of CI so we don't discover issue when trying to cut a release. I would be OK only doing the builds post merge or not including artifacts for CI

Copy link
Member

Choose a reason for hiding this comment

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

Works for me, especially if it's concurrent and doesn't take longer than the existing jobs (doesn't seem to though that poor macos-arm one in last CI run took a really long time). I do think we should skip uploading the artifact though, but not a big deal.

Copy link
Member

@cretz cretz Apr 25, 2025

Choose a reason for hiding this comment

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

Are the test server artifacts on this PR's CI run much larger than what we've released in the past? For instance, Windows x64 on this PR's CI run is 62.4MB (exe inside about the same size), but the one at https://github.com/temporalio/sdk-java/releases is 18.4MB (exe inside about the same size). I wonder if it's due to Java upgrade or if we're inadvertently not trimming something anymore or what.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

hm good callout, not sure let me check

Copy link
Contributor Author

Choose a reason for hiding this comment

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

OK I think I addressed the size by adjusting the optimization level and reverting the extra reflection stuff I was including by mistake

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Once you double check the size I will remove the artifacts from the CI build

Copy link
Member

Choose a reason for hiding this comment

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

It's still slightly bigger. For instance, Linux amd64 in this CI is 22.5MB vs 18.8MB in the last release. I'm ok with that if you are.

Switching topics (sorry, just easy to keep the same thread), I kinda figured the musl-based binary would be bigger than the libc-based one since it should statically link musl. Can you confirm that, unlike glibc build, we statically link musl? (meaning it could technically run on any Linux not just musl-based distros)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

musl is statically linked

Copy link
Member

@cretz cretz Jun 4, 2025

Choose a reason for hiding this comment

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

And I assume you're ok with the ~12% size-after-extracted increase? Checked extracted sizes, for Linux amd64 on release it's 60.3MB but here on CI it's 67.8MB. I don't think I have a big problem with this, though is a bit strange I think to increase sizes for every binary just to add a new musl binary (though I assume/understand it's mostly due to our switching of how we build w/ graal).

Comment on lines 25 to 110
name: Build native test server
strategy:
fail-fast: false
matrix:
include:
- runner: ubuntu-latest
os_family: linux
arch: amd64
musl: true
- runner: ubuntu-latest
os_family: linux
arch: amd64
musl: false
- runner: macos-13
os_family: macOS
arch: amd64
- runner: macos-latest
os_family: macOS
arch: arm64
- runner: ubuntu-24.04-arm
os_family: linux
arch: arm64
- runner: windows-latest
os_family: windows
arch: amd64
runs-on: ${{ matrix.runner }}
steps:
- name: Checkout repo
uses: actions/checkout@v4
with:
fetch-depth: 0
submodules: recursive
ref: ${{ env.INPUT_REF }}

- name: Set up Java
if: matrix.os_family != 'Linux'
uses: actions/setup-java@v4
with:
java-version: |
21
23
distribution: "graalvm"

- name: Set up Gradle
if: matrix.os_family != 'Linux'
uses: gradle/actions/setup-gradle@v4

- name: Build native test server (non-Docker)
if: matrix.os_family != 'Linux'
run: |
./gradlew -PnativeBuild :temporal-test-server:nativeCompile

- name: Build native test server (Docker non-musl)
if: matrix.os_family == 'Linux' && matrix.musl == false
run: |
docker run \
--rm -w /github/workspace -v "$(pwd):/github/workspace" \
$(docker build -q ./docker/native-image) \
sh -c "./gradlew -PnativeBuild :temporal-test-server:nativeCompile"

- name: Build native test server (Docker musl)
if: matrix.os_family == 'Linux' && matrix.musl == true
run: |
docker run \
--rm -w /github/workspace -v "$(pwd):/github/workspace" \
$(docker build -q ./docker/native-image-musl) \
sh -c "./gradlew -PnativeBuild -PnativeBuildMusl :temporal-test-server:nativeCompile"
# path ends in a wildcard because on windows the file ends in '.exe'
- name: Upload executable to workflow
uses: actions/upload-artifact@v4
with:
name: ${{ matrix.musl && format('{0}_{1}_musl', matrix.os_family, matrix.arch) || format('{0}_{1}', matrix.os_family, matrix.arch)}}
path: |
temporal-test-server/build/native/nativeCompile/temporal-test-server*
if-no-files-found: error
retention-days: 1

Check warning

Code scanning / CodeQL

Workflow does not contain permissions

Actions job or workflow does not limit the permissions of the GITHUB_TOKEN. Consider setting an explicit permissions block, using the following as a minimal starting point: {{contents: read}}

Copilot Autofix

AI about 1 month ago

To address the issue, we will add a permissions block to the workflow file. This block will explicitly define the minimal permissions required for the workflow to function correctly. Based on the workflow's actions, it primarily interacts with repository contents (e.g., checking out code) and uploads artifacts. Therefore, the contents: read permission is sufficient for this workflow. We will add the permissions block at the root level of the workflow to apply it to all jobs.


Suggested changeset 1
.github/workflows/build-native-image.yml

Autofix patch

Autofix patch
Run the following command in your local git repository to apply this patch
cat << 'EOF' | git apply
diff --git a/.github/workflows/build-native-image.yml b/.github/workflows/build-native-image.yml
--- a/.github/workflows/build-native-image.yml
+++ b/.github/workflows/build-native-image.yml
@@ -1,2 +1,4 @@
 name: Build native image
+permissions:
+  contents: read
 defaults:
EOF
@@ -1,2 +1,4 @@
name: Build native image
permissions:
contents: read
defaults:
Copilot is powered by AI and may make mistakes. Always verify output.
Unable to commit as this autofix suggestion is now outdated
Comment on lines +196 to +201
name: Build native test server
uses: ./.github/workflows/build-native-image.yml
with:
ref: ${{ github.event.pull_request.head.sha }}

Check warning

Code scanning / CodeQL

Workflow does not contain permissions

Actions job or workflow does not limit the permissions of the GITHUB_TOKEN. Consider setting an explicit permissions block, using the following as a minimal starting point: {{}}

Copilot Autofix

AI about 1 month ago

To fix the issue, we will add a permissions block at the root of the workflow file to define the minimal permissions required for all jobs. Based on the workflow's actions, the contents: read permission is sufficient for most steps, as they involve checking out the repository and running tests. If any job requires additional permissions, we will define a specific permissions block for that job.


Suggested changeset 1
.github/workflows/ci.yml

Autofix patch

Autofix patch
Run the following command in your local git repository to apply this patch
cat << 'EOF' | git apply
diff --git a/.github/workflows/ci.yml b/.github/workflows/ci.yml
--- a/.github/workflows/ci.yml
+++ b/.github/workflows/ci.yml
@@ -1,2 +1,4 @@
 name: Continuous Integration
+permissions:
+  contents: read
 on:
EOF
@@ -1,2 +1,4 @@
name: Continuous Integration
permissions:
contents: read
on:
Copilot is powered by AI and may make mistakes. Always verify output.
Unable to commit as this autofix suggestion is now outdated
@Quinn-With-Two-Ns Quinn-With-Two-Ns force-pushed the musl-build branch 2 times, most recently from 2375763 to 4ee467f Compare May 29, 2025 00:29
@Quinn-With-Two-Ns Quinn-With-Two-Ns requested a review from cretz June 3, 2025 22:10
Copy link
Member

@cretz cretz left a comment

Choose a reason for hiding this comment

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

Nothing blocking, though the size increase for all the existing binaries is unfortunate.

@Quinn-With-Two-Ns Quinn-With-Two-Ns merged commit bdc94f7 into master Jun 11, 2025
18 checks passed
@Quinn-With-Two-Ns Quinn-With-Two-Ns deleted the musl-build branch June 11, 2025 23:12
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.

Support musl-based build of test server
2 participants