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.

Sign up for GitHub

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

Jump to bottom

Update to Gradle 8; resuscitate CI #238

Open
wants to merge 20 commits into
base: master
Choose a base branch
from
Open

Update to Gradle 8; resuscitate CI #238

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
20 commits
Select commit Hold shift + click to select a range
d0e1a27
Linux ARM natives: add FP requirement to arch.
MrDOS Sep 5, 2023
64833b7
macOS natives: don't need to link Java framework.
MrDOS Sep 5, 2023
e542631
macOS natives: specifically target Mac OS X 10.7.
MrDOS Sep 5, 2023
6179070
CI: use evergreen runners; update actions.
MrDOS Sep 5, 2023
e10feb7
CI: build for FreeBSD 11, including arm64.
MrDOS Sep 5, 2023
eef5733
Gradle: apply all of the plugins together.
MrDOS Sep 5, 2023
84a4365
Gradle: remove the deprecated JCenter repository.
MrDOS Sep 5, 2023
712e484
Gradle: remove obsolete reference to `libs/` dir.
MrDOS Sep 5, 2023
a2c9325
Gradle: remove unnecessary JAR configuration.
MrDOS Sep 5, 2023
4cfddf5
Gradle: update dependency configurations names.
MrDOS Sep 5, 2023
f5b383d
Gradle: use automatic Javadoc/source archives.
MrDOS Sep 5, 2023
4155d5a
Gradle: switch to the maven-publish plugin.
MrDOS Sep 5, 2023
63993ca
Gradle: optionally sign publication artifacts.
MrDOS Sep 5, 2023
04072c2
Gradle: update to v8.3.
MrDOS Sep 5, 2023
8200051
Gradle: build with a Java 8 toolchain.
MrDOS Sep 5, 2023
aa32d8d
Gradle: replace base plugin conventional props.
MrDOS Sep 5, 2023
f96d469
Gradle: update Bnd plugin to v6.4.0.
MrDOS Sep 5, 2023
485d70b
Gradle: update Spotless plugin to v6.13.0.
MrDOS Sep 5, 2023
92f2f5c
Gradle: use single-quoted strings where possible.
MrDOS Sep 5, 2023
bcb0063
Gradle: add Sam to the POM's developer list.
MrDOS Sep 5, 2023
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
71 changes: 43 additions & 28 deletions .github/workflows/build.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -6,23 +6,32 @@ on:
jobs:
natives-linux-windows:
name: Linux (x86/ARM/PPC) and Windows native library compilation
runs-on: ubuntu-18.04
runs-on: ubuntu-latest
container:
image: ubuntu:18.04
env:
GCC: gcc-8

defaults:
run:
working-directory: src/main/c

steps:
- name: Checkout the target branch
uses: actions/checkout@v2
uses: actions/checkout@v3
- name: Setup Java
uses: actions/setup-java@v1
uses: actions/setup-java@v3
with:
distribution: temurin
java-version: 8
# Don't need the dependency cache here (or in any of the other native
# library compilation steps), because we're not invoking the Java
# compiler in this step. We only need the JDK for its headers.
- name: Install build prerequisites
run: |
sudo apt update
sudo make crosstools
apt-get update
apt-get --assume-yes install make $GCC
make crosstools

- name: Build the Linux and Windows native libraries
run: |
Expand All @@ -33,36 +42,37 @@ jobs:
# exactly to the directories inside `src/main/c/resources/native`. That
# way, the Java build job can pull down all artifacts and unpack them
# into that directory to overwrite the versions in-repo. This is sadly
# necessary because the actions/download-artifact@v2 action flattens
# necessary because the actions/download-artifact@v3 action flattens
# paths inside artifacts. If it retained full relative paths, we could
# put Linux and Windows natives inside the same artifact, and we could be
# flexible with the artifact names. But it doesn't, so we can't, and we
# can't.
- name: Upload Linux native libraries
uses: actions/upload-artifact@v2
uses: actions/upload-artifact@v3
with:
name: linux
path: src/main/c/resources/native/linux
- name: Upload Windows native libraries
uses: actions/upload-artifact@v2
uses: actions/upload-artifact@v3
with:
name: windows
path: src/main/c/resources/native/windows

natives-macos:
name: macOS native library compilation
runs-on: macos-10.15
runs-on: macos-latest

defaults:
run:
working-directory: src/main/c

steps:
- name: Checkout the target branch
uses: actions/checkout@v2
uses: actions/checkout@v3
- name: Setup Java
uses: actions/setup-java@v1
uses: actions/setup-java@v3
with:
distribution: temurin
java-version: 8

- name: Build the macOS native libraries
Expand All @@ -71,49 +81,52 @@ jobs:
make osx

- name: Upload macOS native libraries
uses: actions/upload-artifact@v2
uses: actions/upload-artifact@v3
with:
name: osx
path: src/main/c/resources/native/osx/libNRJavaSerial.jnilib

natives-freebsd:
name: FreeBSD native library compilation
runs-on: ubuntu-18.04
runs-on: ubuntu-latest
container:
image: empterdose/freebsd-cross-build:9.3
env:
JAVA_HOME: /usr/lib/jvm/default-jvm
image: empterdose/freebsd-cross-build:11.4

defaults:
run:
working-directory: src/main/c

steps:
- name: Checkout the target branch
uses: actions/checkout@v2
uses: actions/checkout@v3
- name: Setup Java
uses: actions/setup-java@v3
with:
distribution: temurin
java-version: 8
- name: Fake the FreeBSD Java headers
# This feels extremely dirty, but the only native header we care about
# is `jni_md.h`, and it is exactly identical between Linux and FreeBSD
# (at least in OpenJDK 8).
run: |
apk add openjdk8
ln -s $JAVA_HOME/include/linux $JAVA_HOME/include/freebsd

- name: Build the FreeBSD native libraries
run: |
make clean-freebsd
settarget i386-freebsd9 make freebsd32
settarget x86_64-freebsd9 make freebsd64
settarget i386-freebsd11 make freebsd32
settarget x86_64-freebsd11 make freebsd64
settarget arm64-freebsd11 make freebsdarm64v8

- name: Upload FreeBSD native libraries
uses: actions/upload-artifact@v2
uses: actions/upload-artifact@v3
with:
name: freebsd
path: src/main/c/resources/native/freebsd

java:
name: Java compilation
runs-on: ubuntu-18.04
runs-on: ubuntu-latest
Copy link
Member

Choose a reason for hiding this comment

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

I would suggest pinning versions, generally as it ensures that a previous build can be re-built, later in time when "latest" changes

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I was actually hoping to use evergreen runner versions as a canary to help catch places where the build process accidentally relies on the default version of something in the runner image. IMO because GitHub frequently update tools within the runner images, just pinning the runner version alone doesn't guarantee much stability. I'm hoping that the other changes I've made make the runner version irrelevant to reproducibility:

  • The Linux/Windows build step now runs inside an Ubuntu 18.04 container, and so we're using the fixed version of GCC 8 shipped for that environment.
  • Same story for the FreeBSD build step; all of the meaningful work runs in the cross-compiler container.
  • The macOS build now specifically targets Mac OS X 10.7 at minimum, so (in theory) it doesn't matter what version of Xcode or macOS SDK you're using. Apple clang still happily accepts -target values for long-EOL'd OSes (right down to 10.0), so I think we should be fairly able to use just about any Xcode tools/macOS SDK and get a functionally-identical (if admittedly not byte-identical) product.
  • The Java build doesn't use any native tools at all. We configure a Java 8 JDK before we hop into Gradle, and that should be the end of the reliance on the surrounding, non-Java environment. And even if we didn't do that, the Gradle build definition specifically requires a Java 8 toolchain such that if Gradle wasn't launched by a Java 8 JDK, it will go off, download one, and use that to make the builds. (It's really neat to watch it do it, actually – launch the build from a Java 17 environment and it goes off and fetches a compiler like it would any other dependency.)

I hear where you're coming from, though. It's tedious when a PR gets held up because the build system has shifted underneath you. I can change the jobs to ubuntu-22.04/macos-12 if you'd prefer.

Copy link
Member

Choose a reason for hiding this comment

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

cool, that works, thanks.


needs:
- natives-linux-windows
Expand All @@ -126,18 +139,20 @@ jobs:
# don't regress formatting when compared with the master branch, we need
# to have a local copy of the master branch for comparison.
- name: Checkout the master branch
uses: actions/checkout@v2
uses: actions/checkout@v3
with:
ref: master
- name: Checkout the target branch
uses: actions/checkout@v2
uses: actions/checkout@v3
- name: Setup Java
uses: actions/setup-java@v1
uses: actions/setup-java@v3
with:
distribution: temurin
java-version: 8
cache: gradle

- name: Download native libraries
uses: actions/download-artifact@v2
uses: actions/download-artifact@v3
with:
path: src/main/c/resources/native

Expand All @@ -146,9 +161,9 @@ jobs:

- name: Determine commit hash for artifact filename
id: vars
run: echo "::set-output name=short-rev::$(git rev-parse --short HEAD)"
run: echo "short-rev=$(git rev-parse --short HEAD)" >>$GITHUB_OUTPUT
- name: Upload build artifacts
uses: actions/upload-artifact@v2
uses: actions/upload-artifact@v3
with:
name: nrjavaserial-${{steps.vars.outputs.short-rev}}
path: build/libs/*.jar
7 changes: 7 additions & 0 deletions README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -70,6 +70,13 @@ ease of use and embeddability in other libraries.

The resulting JAR will be found in the `build/libs/` directory.

Optionally, you can publish (“install”) your new build
into your local Maven repository (`~/.m2/repository`).
That way, you easily can consume your own build of the library
from other locally-built Maven/Gradle projects.

$ ./gradlew publishToMavenLocal

# Building the native libraries

The native libraries are written in C,
Expand Down
Loading
Loading