Each workflow profile is defined in this repository as a GitHub Workflow, using YAML. In some cases, workflows are paired with a container image which includes the tools which are used by the workflow. The image typically isn't required (unless noted) but may vastly speed up builds by pre-including tools.

For an exhaustive list of build profiles and their use, see the table further down.

• Containers: Container image definitions which are used by actions and workflows; some of these can also be used directly in downstream workflows.

• Actions: Custom GitHub Actions for use in Elide codebases. Actions are used like any other GitHub Action, but with references to this repository instead.

• Workflows: Custom YAML workflow definitions for use in Elide codebases. Workflows are used as external workflow_call targets.

• Gradle: Gradle build conventions which are re-usable across projects, as a suite of easily applicable build convention plugins and version catalogs.

In a .github/workflows/<x>.yml:

# ...

jobs:
  ## Build container
  build-a-container:
    name: "Image"
    uses: elide-dev/build-infra/.github/workflows/container.yml@main
    secrets: inherit
    permissions:
      checks: write
      id-token: write
      contents: read
      packages: write
      pull-requests: write
    with:
      image: elide-dev/build-infra/gvm
      path: containers/gvm
      push: ${{ github.event_name == 'push' && github.ref == 'refs/heads/main' }}

The above job uses the container.yml "build profile" (see all profiles listed below). By using the re-usable workflow, you gain consistency:

• Repository authentication is handled for you
• Intelligent platform selection (with override)
• Consistent tagging and labeling of images
• Underlying Github Actions updates happen without repo commits

See below for documentation about reusable workflow inputs.

See below for an exhaustive list of all inputs for each build profile. You can use these inputs in the with: {} block of your workflow invocation.

• Description: Consistently build properly tagged container images in sync with source control
• Workflow: .github/workflows/container.yml

• Description: Consistently build JVM outputs using Gradle
• Workflow: .github/workflows/jvm.gradle.yml

• Description: Consistently build JVM outputs using Gradle
• Workflow: .github/workflows/jvm.gradle.yml

• Description: Consistently build JVM outputs using Maven
• Workflow: .github/workflows/jvm.maven.yml

Inputs for the Maven workflow are nearly identical to those for the Gradle workflow (listed above):

• Description: Run builds with Bazel
• Workflow: .github/workflows/bazel.yml

There are no required inputs for a Bazel build; the target specification defaults to the value //..., which builds all targets. The default command is build. The build is executed with Bazelisk, which will respect the .bazelversion present at the root of your project.

The Gradle conventions provided by this project are generic in nature and can be used in nearly any Gradle 8 project. Conventions are applied in a cascading fashion, with relevant plugins being applied first, which then provide strong baseline settings.

Gradle infra:

• Plugins for common build tasks, especially around JPMS. See the plugins list below.
• Catalogs defining security-hardened library catalogs
• Platforms which enforce different profiles of dependency constraints

Read more about the Gradle build infra here. There are samples.

• dev.elide.gha: Integrate your Gradle build with GitHub Actions. Enables enhanced logging and reporting features, PR integrations, and other features supported by the workflows in this repo.

• dev.elide.jmod: Build jmod artifacts in Gradle JVM projects with Java 9 . jmod artifacts are compatible with jlink and make for great optimized build artifacts in modular projects.

• dev.elide.jpms: Toolkit plugin for Gradle builds enabled with modular Java (Java Platform Module System, or JPMS). Provides a modulepath configuration and modular builds for Java, Kotlin, and GraalVM.

• dev.elide.mrjar: Plugin for easily building multi-target MRJAR artifacts. This plugin goes above and beyond by building the entire project at each bytecode tier, so that modern Java runtimes can leverage the latest bytecode.

• dev.elide.jlink: Plugin for using jmod and jpms to build optimized, self-contained modular Java apps using jlink.

• dev.elide.graalvm: Plugin for using jmod and jpms to build optimized, native AOT Java apps using native-image.

Follow the YAML and action convention within the repository; the multi-workspace expressed here for actions uses the GitHub Actions Toolkit and pnpm workspaces.

Build configurations are validated on each push, and actions are built and tested to the extent possible. Once a PR is merged, it is expected to be deployed to private package storage, where update tools can pick it up.

This repository is shared openly for OSS use. It is licensed as MIT.