# toolchains Toolchains are collections of compiler and utility tools used to build software, with frameworks such as Bazel and CMake selecting or configuring them for platforms and languages. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Google joins the OpenROAD Initiative as principal member to accelerate open source silicon innovation DevFeed: [Google joins the OpenROAD Initiative as principal member to accelerate open source silicon innovation]() Original publisher: [Read original article]() Author: Google Open Source (noreply@blogger.com) Published: 2026-08-11T18:30:00Z Content type: release Language: en Sources: [Google Open Source Blog]() Topics: [Google](), [Chip design](), [Open Source](), [toolchains](), [Continuous integration]() Tags: [chip-design](), [ci-cd](), [eda](), [google](), [open-source](), [openroad](), [semiconductors](), [toolchains](), [user-experience]() ### AI overview Google has joined the OpenROAD Initiative as a principal member and appointed Aaron Cunningham to its Governing Board. The partnership supports OpenROAD's open-source electronic design automation ecosystem through governance, ecosystem growth, workforce development, and technical improvements. ### Source excerpt by Ethan Mahintorabi & Aaron Cunningham, Hardware Toolchains Team Google is committed to advancing open source silicon innovation. We are excited to share that we have formally joined the OpenROAD Initiative (ORI), Inc. as a principal member. ORI is a nonprofit public benefit corporation dedicated to the open source electronic design automation (EDA) ecosystem. As part of this commitment, Aaron Cunningham has been appointed to the ORI Governing Board to represent Google and help drive the foundation's strategic direction, financial sustainability, and technical stewardship. Driving long-term open source sustainability The OpenROAD Initiative's mission is to advance and sustain the open source EDA ecosystem by fostering collaborative innovation across research, education, and industry--transforming ideas into silicon. Google's membership aligns directly with ORI's multi-year sustainability goals, supported by the US National Science Foundation's (NSF) Pathways to Enable Open-Source Ecosystems (POSE) program. With Google's participation and membership commitment, ORI will continue to strengthen, grow, and sustain its open source ecosystem through key vectors: Neutral Stewardship: Fostering transparent governance where no single company has outsized control over the code, ensuring the project remains inspectable, accessible, and community-driven. Ecosystem Growth: Supporting open and reproducible silicon research, developing robust design flows, and hosting global design contests. Workforce Development: Supporting global silicon skilling initiatives by expanding open source chip design curricula and collaborating with academic institutions and industrial training networks. Technical Strengthening: Enhancing continuous integration and deployment (CI/CD) pipelines, expanding PDK enablement, and improving user experience. Leadership perspectives "The OpenROAD Initiative is built on the vision of making chip design open and accessible to all--building a collaborative ecosyst ## GC and Exceptions in Wasmtime DevFeed: [GC and Exceptions in Wasmtime]() Original publisher: [Read original article]() Author: Nick Fitzgerald Published: 2026-07-20T00:00:00Z Content type: release Language: en Sources: [Bytecode Alliance]() Topics: [WebAssembly](), [wasm](), [Exception](), [toolchains]() Tags: [compilation](), [exceptions](), [release](), [toolchains](), [wasm](), [webassembly]() ### AI overview Wasmtime 47 enables the Wasm GC and exceptions proposals by default. The article explains how Wasm GC supports languages with object-and-reference data models by letting the runtime manage types and lifetimes, while the exceptions proposal provides more efficient exception handling for WebAssembly compilation targets. ### Source excerpt The Wasm GC and exceptions proposals are both enabled by default in today's Wasmtime 47 release! We are excited to help bring more languages to WebAssembly and everywhere that Wasmtime runs. Getting to this point involved large Wasmtime changes and represents the culmination of years of engineering effort. ## ESPHome 2026.7.0: Native toolchains by default DevFeed: [ESPHome 2026.7.0: Native toolchains by default]() Original publisher: [Read original article]() Author: Jesse Hills Published: 2026-07-15T00:00:00Z Content type: release Language: en Sources: [ESPHome - Smart Home Made Simple - Blog]() Topics: [esphome](), [toolchains](), [ESP32](), [Modbus](), [Security](), [ESP-IDF](), [SDK]() Tags: [2026](), [esp-idf](), [esp32](), [esphome](), [modbus](), [native](), [release](), [releases](), [security](), [toolchains]() ### AI overview ESPHome 2026.7.0 makes native ESP32 and nRF52 toolchains the default, adds security infrastructure including NVS encryption and OTA downgrade protection, and introduces a transport-agnostic provisioning component. The release also overhauls Modbus and includes performance, memory, LVGL, Ethernet, ESP-NOW, Zigbee, and component updates. ### Source excerpt ESPHome 2026.7.0 makes native toolchains the default on ESP32 and nRF52, adds EN18031 security groundwork, and overhauls Modbus. ## How Gradle Is Javamaxxing DevFeed: [How Gradle Is Javamaxxing]() Original publisher: [Read original article]() Author: Laura Kassovic Published: 2026-05-28T04:00:00Z Content type: article Language: en Sources: [The Gradle Blog]() Topics: [Gradle](), [Java](), [toolchains](), [toolchain]() Tags: [bytecode](), [compiler](), [garbage-collectors](), [gradle](), [java](), [java-8](), [jdk](), [jvm](), [openjdk](), [optimization](), [performance-optimization](), [release]() ### AI overview Gradle aggressively adopts new JDK releases because newer JVMs can improve build speed, memory use, startup behavior, and maintainability. JVM toolchains allow Gradle to run on JDK 26 while compiling and testing projects for older Java versions, including producing Java 8-compatible bytecode. ### Source excerpt Some people optimize one part of their lives to the absolute limit, then past it. They call it "-maxxing." Houseplantmaxxing. Sleepmaxxing. Tokenmaxxing. The Gradle Build Tool is Javamaxxing. TL;DR Breathe easy knowing you can run modern Gradle on JDK 26 while still shipping Java 8-compatible artifacts: Gradle aggressively adopts new JDKs because newer JVMs make builds faster, leaner, and easier to maintain. Upgrading the JDK that runs Gradle is often the easiest performance win. JVM toolchains fully separate the JVM running Gradle, the JVM compiling your code, and the JVM running your tests. NOT TL;DR We aggressively adopt new JDK releases as soon as we responsibly can. Not because it's trendy. Because newer JDKs make Gradle faster, leaner, and easier to maintain. Every OpenJDK release ships improvements to the JVM; garbage collectors, compiler infrastructure, startup behavior, memory layout, and runtime APIs. As a high-performance JVM build tool, Gradle benefits directly from all of it. The question people immediately ask is: Does this mean my project also has to run on the newest JDK? No. That coupling effectively disappeared once Gradle introduced JVM toolchains. With toolchains, the JVM that runs Gradle is completely separate from the JVM that compiles, tests, and executes your code. You can run Gradle on JDK 26 today and still produce Java 8 bytecode. What Is the Current State of Gradle and Java? We add daemon support for every new JDK as soon as the ecosystem permits: Java 24 in Gradle 8.14.0, Java 25 in 9.1.0 (released two days after JDK 25 GA), Java 26 in 9.4.0. The full mapping is in the Compatibility Matrix. We then bump the minimum JVM required to execute Gradle as users move. Gradle 9.0.0, released on July 31, 2025, raised the minimum JVM required to run the Gradle daemon to Java 17. That was the first daemon JVM floor increase since Gradle 5.0 made Java 8 the minimum back in 2018. The next major transition is already underway, Gradle 10.0.0 will likely ## Architectural Choices in China's Open-Source AI Ecosystem: Building Beyond DeepSeek DevFeed: [Architectural Choices in China's Open-Source AI Ecosystem: Building Beyond DeepSeek]() Original publisher: [Read original article]() Author: Adina Yakefu; Irene Solaiman Published: 2026-01-27T15:01:45Z Content type: article Language: en Sources: [Hugging Face - Blog]() Topics: [Open Source](), [Artificial Intelligence](), [Mixture of Experts (MoE)](), [Hardware](), [multimodal](), [Open Source Models & Datasets](), [Inference](), [model-deployment](), [datasets](), [toolchains](), [stable-diffusion]() Tags: [ai](), [china](), [compute](), [datasets](), [deployment](), [evaluation](), [mixture-of-experts-moe](), [multimodal](), [open-source](), [performance](), [text-to-image](), [toolchains]() ### AI overview This second article in a three-part series examines architectural and hardware choices in China's open-source AI ecosystem after the DeepSeek Moment. It explains why Mixture-of-Experts architectures became widespread, emphasizing flexible compute allocation, sustainable cost-performance balance, deployment across varied hardware, and expansion into multimodal models, agents, datasets, evaluation, and toolchains. ### Source excerpt This is the second blog in a three-part series on China's open source community's historical advancements since January 2025's "DeepSeek Moment." The first blog is available here, and the third blog is available here. In this second piece we turn our focus from models to the architectural and hardware choices Chinese companies have made as openness becomes the norm. ## Engineers Want to Build, Not Maintain: Key Findings From Our 2026 Engineering Reality Report DevFeed: [Engineers Want to Build, Not Maintain: Key Findings From Our 2026 Engineering Reality Report]() Original publisher: [Read original article]() Published: 2025-10-08T00:00:00Z Content type: article Language: en Sources: [Chainguard: Unchained]() Topics: [Developer experience](), [code productivity](), [Artificial Intelligence](), [Automation](), [toolchains](), [Security]() Tags: [2026](), [ai](), [automation](), [chainguard](), [chainguard-containers-report](), [chainguard-report](), [developer-experience](), [developer-experience-report](), [engineering-reality](), [engineering-reality-2025](), [productivity](), [report](), [secure-software](), [security](), [software-engineer](), [toolchains]() ### AI overview Chainguard's 2026 Engineering Reality Report, based on a survey of 1,200 engineers and technology leaders, examines the modern developer experience. It finds that automation and AI are reducing repetitive work, while technical debt, maintenance, fragmented tooling, workflow disruption, burnout, and limited trust continue to constrain productivity. Engineers consistently want more time to build, and the article connects secure, integrated tools with innovation and business growth. ### Source excerpt Chainguard surveyed 1,200 engineers and technology leaders to better understand the state of the developer experience today and where teams can improve. ## Malicious MCP Server on npm postmark-mcp Harvests Emails DevFeed: [Malicious MCP Server on npm postmark-mcp Harvests Emails]() Original publisher: [Read original article]() Author: Liran Tal Published: 2025-09-25T04:00:00Z Content type: news Language: en Sources: [Blog RSS Feed | Snyk]() Topics: [MCP Server](), [supply-chain-security](), [npm](), [incident](), [Security](), [toolchains]() Tags: [agent](), [agents](), [ai](), [awareness](), [backdoor](), [blog](), [devrel](), [incident](), [mcp](), [mcp-server](), [npm](), [open-source-security](), [pii](), [secrets](), [security](), [snyk](), [supply-chain](), [supply-chain-security](), [tokens](), [vulnerability-insights]() ### AI overview This security article reports that the npm package postmark-mcp, an MCP Server for sending email through Postmark, was modified in September 2025 to secretly add a BCC forwarding emails to an external domain. It outlines the incident timeline, the email data and credentials potentially at risk, and mitigation steps including uninstalling the package, rotating credentials, reviewing email logs, and scanning with Snyk's MCP-Scan. ### Source excerpt Urgent security alert: On September 25, 2025, the npm package 'postmark-mcp' was compromised, secretly exfiltrating email contents. Learn about the incident timeline, impact, and immediate mitigation steps, including uninstalling, rotating credentials, and scanning with Snyk's MCP-Scan. ## Demonstrably Secure Software Supply Chains with Nix DevFeed: [Demonstrably Secure Software Supply Chains with Nix]() Original publisher: [Read original article]() Author: Jacek Galowicz Published: 2025-05-12T00:00:00Z Content type: article Language: en Sources: [Nixcademy Blog]() Topics: [Nix](), [supply-chain-security](), [open-source-security](), [integrity](), [Security](), [toolchains](), [audit]() Tags: [audit](), [audits](), [builds](), [capabilities](), [compilers](), [compliance](), [environments](), [government](), [integrity](), [local](), [offline](), [organizations](), [rebuilds](), [secure-software](), [security](), [software](), [software-supply-chain](), [software-supply-chain-security](), [supply-chain](), [supply-chain-security]() ### AI overview This article explains how Nix can support verifiable software supply chain integrity. It describes tracing sources and toolchains, enabling hermetic offline rebuilds, and exporting release sources for audits to help meet regulatory requirements. ### Source excerpt Discover how Nix can revolutionize your software supply chain security, enabling verifiable integrity and offline rebuilds from source. ## Finding unused targets with bazel DevFeed: [Finding unused targets with bazel]() Original publisher: [Read original article]() Author: Keith Smiley Published: 2025-03-24T18:00:00Z Content type: tutorial Language: en Sources: [Keith Smiley]() Topics: [Graphs](), [coding](), [Code](), [toolchains]() Tags: [bazel](), [build](), [code](), [coding](), [dependencies](), [graph](), [toolchains](), [use-cases]() ### AI overview This article explains how to use bazel query to inspect a build graph and identify unused targets. It presents a query that subtracts dependencies of top-level targets from all first-party targets, then discusses handling edge cases with kind filters and special tags such as allow-unused. It also describes tagging toolchains and other targets whose dependencies should be treated as used. ### Source excerpt Once you've fully migrated a codebase to bazel, one of the many advantages is that you can easily inspect your build graph using bazel query. One of the many things you can do with queries is write scripts to enforce coding standards, or in today's example, find unused targets that can lead to discovering unused code. The simplest version of this query starts like this: let all_targets = //... in let top_level_targets = tests($all_targets) union kind("(.*_binary) rule", $all_targets) in $all_targets - deps($top_level_targets) This initial version discovers all your first party targets, and then subtracts the dependencies of all "top level" targets, so that any remaining targets are considered unused. The idea of "top level" targets is better defined as: anything that you consider to be important enough that its dependencies are used. Depending on your codebase you might want to exclude test targets from this so that targets only in the dependencies of test targets are diagnosed as unused (this won't work if you have intentional testonly dependencies, although you could special case those as shown below). Once you have this initial query, you can start iterating in order to handle in edge cases. For example it's likely that you have some targets that aren't binaries or tests, but are considered used. There are 2 approaches I would recommend to handle this. First you can continue to build out the kind filter: kind("(.*_binary|platform|test_suite) rule", $all_targets) The downside with this approach is it can get unwieldy quickly. I like adding rules here that have many uses, but for other one off cases another approach you can use is to expand the query to look for special tags: let all_targets = //... in let top_level_targets = tests($all_targets) union kind("(.*_binary|platform|test_suite) rule", $all_targets) in let allowed_unused = attr(tags, allow-unused, $all_targets) in $all_targets - deps($top_level_targets) - $allowed_unused Then you can add tags = ["allow-un ## From XAMPP to Ephemeral Postgres: Where "Works on My Machine" Has Led Us DevFeed: [From XAMPP to Ephemeral Postgres: Where "Works on My Machine" Has Led Us]() Original publisher: [Read original article]() Author: Andrew Tate Published: 2025-02-27T00:51:30Z Content type: article Language: en Sources: [Blog -- Neon Docs]() Topics: [Web Development](), [XAMPP](), [MySQL](), [PHP](), [configuration](), [Databases](), [Package Management](), [toolchains](), [Open Source]() Tags: [apache](), [coding](), [community](), [configuration](), [database](), [databases](), [debugging](), [dependencies](), [developers](), [development](), [environment-variables](), [installations](), [libraries](), [local](), [mysql](), [open-source](), [package-management](), [php](), [servers](), [source](), [systems]() ### AI overview This article looks back at local web development in the 1990s, when developers manually installed and configured Apache, PHP, and databases such as MySQL and Postgres. It describes environment drift, dependency and version conflicts, difficult database setup, manual configuration, and the technical understanding that these constraints encouraged. ### Source excerpt "It works on my machine" is now a trope--a horror story to tell young developers (or AI coding models) about what it was like to build without today's stack. Like all clichés, it was once true. Hodgepodge local installs, no containers, and massive environment drift were challenges... ## Gradle toolchains are rarely a good idea DevFeed: [Gradle toolchains are rarely a good idea]() Original publisher: [Read original article]() Published: 2024-03-21T00:00:00Z Content type: opinion Language: en Sources: [Jake Wharton]() Topics: [Gradle](), [toolchains](), [Java](), [Containers](), [ci](), [Homebrew](), [Kotlin]() Tags: [ci](), [containers](), [go](), [gradle](), [java](), [toolchains]() ### AI overview The article argues that Gradle Java toolchains are often counterproductive. Using an old JDK can produce outdated, non-searchable Javadoc, ignore container resource limits, and increase the risk of compiler and JVM bugs. The author recommends building with a modern JDK while controlling the target language level through compiler configuration, and keeping installed JDKs up to date. ### Source excerpt The last post featured some Kotlin code inadvertently targeting a new Java API when the build JDK was bumped to 21. This can be solved with the -Xjdk-release Kotlin compiler flag, or by using Gradle toolchains to build with an old JDK. If you read the Gradle docs... Using Java toolchains is a preferred way to target a language version ...or the Android docs... We recommend that you always specify the Java toolchain ...you wouldn't be blamed for thinking Java toolchains are the way to go! However, Java toolchains are rarely a good idea. Let's look at why. Bad docs Last week I released a new version of Retrofit which uses a Java toolchain to target Java 8. Its use of toolchains was contributed a while ago, and I simply forgot to remove it. As a consequence, its Javadoc was built using JDK 8 and is thus not searchable. Searchable Javadoc came in JEP 225 with JDK 9. The next release of Retrofit will be made without a toolchain and with the latest JDK. Its docs will have all the Javadoc advancements from the last 10 years including search and better modern HTML/CSS. Resource ignorance Old JVMs were somewhat notorious for being ignorant to resource limitations imposed by the system. The rise of containers, especially on CI systems, means your process resource limits are different from those of the host OS. JDK 10 kicked things into high gear with cgroups support and JDK 15 extended that to cgroups2. Both of those changes were backported to the 8 and 11 branches, but since Gradle toolchains will use an already-installed JDK if available you have to have kept your JDK 8 and/or JDK 11 up-to-date. Have you? Not to stray too far off-topic, but if you installed it with SDKMAN! or similar JDK management tools there's a good chance it's wildly out of date. I keep all my JDKs up-to-date by installing them through a Homebrew tap which itself updates automatically using the Azul Zulu API. As long as I do a brew upgrade every so often, each major JDK release that I have installed will be upd ## Building with nightly Swift toolchains on macOS DevFeed: [Building with nightly Swift toolchains on macOS]() Original publisher: [Read original article]() Author: Ole Begemann Published: 2024-03-05T18:54:44Z Content type: tutorial Language: en Sources: [Ole Begemann]() Topics: [Swift](), [toolchains](), [macOS](), [Command-line interface](), [Xcode](), [Package manager]() Tags: [command-line](), [macos](), [swift](), [swift-package-manager](), [toolchains](), [xcode]() ### AI overview A practical guide to installing and selecting nightly Swift compiler toolchains on macOS. It covers using custom toolchains in Xcode and from the command line, including the TOOLCHAINS environment variable and bundle IDs. The article also notes limitations such as unsupported playgrounds, built-in Swift Package Manager behavior, and App Store submission restrictions. ### Source excerpt The Swift website provides nightly builds of the Swift compiler (called toolchains) for download. Building with a nightly compiler can be useful if you want to check if a bug has already been fixed on main, or if you want to experiment with upcoming language features such as Embedded Swift, as I've been doing lately. A toolchain is distributed as a .pkg installer that installs itself into /Library/Developer/Toolchains (or the equivalent path in your home directory). After installation, you have several options to select the toolchain you want to build with: In Xcode In Xcode, select the toolchain from the main menu (Xcode > Toolchains), then build and/or run your code normally. Not all Xcode features work with a custom toolchain. For example, playgrounds don't work, and Xcode will always use its built-in copy of the Swift Package Manager, so you won't be able to use unreleased SwiftPM features in this way. Also, Apple won't accept apps built with a non-standard toolchain for submission to the App Store. On the command line When building on the command line there are multiple options, depending on your preferences and what tool you want to use. The TOOLCHAINS environment variable All of the various Swift build tools respect the TOOLCHAINS environment variable. This should be set to the desired toolchain's bundle ID, which you can find in the Info.plist file in the toolchain's directory. Example (I'm using a nightly toolchain from 2024-03-03 here): # My normal Swift version is 5.10 $ swift --version swift-driver version: 1.90.11.1 Apple Swift version 5.10 (swiftlang-5.10.0.13 clang-1500.3.9.4) # Make sure xcode-select points to Xcode, not to /Library/Developer/CommandLineTools # The Command Line Tools will ignore the TOOLCHAINS variable. $ xcode-select --print-path /Applications/Xcode.app/Contents/Developer # The nightly toolchain is 6.0-dev $ export TOOLCHAINS=org.swift.59202403031a $ swift --version Apple Swift version 6.0-dev (LLVM 0c7823cab15dec9, Swift 0cc0590933 ## Dev Mode: Building a design tool that works harder for developers DevFeed: [Dev Mode: Building a design tool that works harder for developers]() Original publisher: [Read original article]() Author: Alia Fite Published: 2023-11-22T00:00:00Z Content type: article Language: en Sources: [Figma Blog]() Topics: [Figma](), [developer tooling](), [toolchains](), [React](), [Code generation]() Tags: [code](), [developer-tooling](), [developers](), [development](), [figma](), [product-design](), [react](), [tool](), [toolchains](), [workflows]() ### AI overview Figma describes how its Dev Mode team built a developer-focused experience within the design tool. The team moved away from a code-generation-first approach, studied developer workflows and toolchains, and accelerated development through its 2021 acquisition of Visly, whose team had built a tool for developing UI components in React. ### Source excerpt How do you create a home for developers in a design tool? The Dev Mode team shares their early pivot away from a codegen-first approach, the acquisition that accelerated their efforts, and what it means to break down the handoff wall. ## Announcing Lit 3.0 Pre-releases DevFeed: [Announcing Lit 3.0 Pre-releases]() Original publisher: [Read original article]() Author: Justin Fagnani Published: 2023-05-15T00:00:00Z Content type: release Language: en Sources: [Lit Blog]() Topics: [releases](), [Web Components](), [Web](), [npm](), [toolchains](), [interoperability](), [Server-side rendering]() Tags: [browser](), [compatibility](), [interoperability](), [npm](), [packages](), [pre-release](), [release](), [releases](), [ssr](), [testing](), [toolchains](), [tooling](), [upgrade]() ### AI overview The Lit team announces the first Lit 3.0 pre-releases. This major version introduces a small set of breaking changes focused on browser support, deprecated APIs, package publishing, and SSR hydration modules, while adding no new features. Lit 2.x users without deprecation warnings should generally have a seamless upgrade, although some may need newer tooling because Lit's npm modules are now published as ES2021. ### Source excerpt Get an early look at the upcoming Lit 3.0 release. ## Build on latest Java, test through lowest Java DevFeed: [Build on latest Java, test through lowest Java]() Original publisher: [Read original article]() Published: 2022-05-17T00:00:00Z Content type: tutorial Language: en Sources: [Jake Wharton]() Topics: [ci](), [Gradle](), [Java](), [Testing](), [toolchains](), [Open Source]() Tags: [ci](), [gradle](), [java](), [open-source](), [testing](), [toolchains](), [verification]() ### AI overview This article explains how to use Gradle toolchains to compile a Java project once with the latest Java version while running tests across every supported version down to the lowest. The approach reduces CI workload and is especially useful for projects whose behavior or API usage varies by Java version. ### Source excerpt In the past, when a new version of Java was released, I would add that version to our open source project's CI builds. strategy: matrix: java-version: - 8 - 9 ⋮ - 17 + - 18 This ensures that each project can be built and its tests pass on every major version. But this makes no sense! No user is building these projects on different versions. No user is building these projects at all. Consumers are using the pre-built .jar which we ship to Maven Central built on a single version. Testing on every version, however, is something extremely valuable. Thankfully, Gradle toolchains let us retain this while still only building once. First, CI only has to build on a single version. We choose the latest because Java has excellent cross-compilation capabilities, and we want to be using the latest tools. - uses: actions/setup-java@v2 with: distribution: 'zulu' - java-version: ${{ matrix.java-version }} + java-version: 18 Second, unchanged from before, we still target whichever Java version is the lowest supported through either the --release flag or sourceCompatibility/targetCompatibility per the Gradle docs. And finally, we set up tests to run on every supported version. // Normal test task runs on compile JDK. (8..17).each { majorVersion -> def jdkTest = tasks.register("testJdk$majorVersion", Test) { javaLauncher = javaToolchains.launcherFor { languageVersion = JavaLanguageVersion.of(majorVersion) } description = "Runs the test suite on JDK $majorVersion" group = LifecycleBasePlugin.VERIFICATION_GROUP // Copy inputs from normal Test task. def testTask = tasks.getByName("test") classpath = testTask.classpath testClassesDirs = testTask.testClassesDirs } tasks.named("check").configure { dependsOn(jdkTest) } } This setup reduces CI burden since we only compile the main and test sources once but execute the tests on every supported version from latest to lowest. Verification tasks ------------------ check - Runs all checks. test - Runs the test suite. testJdk10 - Runs the test sui ## How to Integrate Just-In-Time Access Requests into Your DevOps Workflow DevFeed: [How to Integrate Just-In-Time Access Requests into Your DevOps Workflow]() Original publisher: [Read original article]() Author: info@goteleport.com (Steven Martin) Published: 2021-11-11T00:00:00Z Content type: tutorial Language: en Sources: [Teleport]() Topics: [DevOps](), [Zero Trust](), [certificates](), [toolchains](), [Command-line interface](), [Containers](), [Slack](), [email](), [GitLab](), [Amazon EC2]() Tags: [api](), [aws](), [containers](), [devops](), [email](), [gitlab](), [how-to](), [implement](), [jira](), [least-privilege](), [on-call](), [organization](), [pagerduty](), [request](), [server](), [speed](), [ssh](), [toolchains](), [workflow](), [zero-trust]() ### AI overview This tutorial explains how Teleport Access Requests provide temporary elevated infrastructure access for DevOps workflows. It covers approval through command-line, web console, and plugins such as Slack, PagerDuty, Jira, Email, and GitLab, with short-lived certificates reverting to default roles after the access period. ### Source excerpt Just-in-time access requests enable DevOps teams to implement least privilege without introducing roadblocks to productivity. This post shows you how to get started. ## Introducing Java toolchains DevFeed: [Introducing Java toolchains]() Original publisher: [Read original article]() Author: Louis Jacomet Published: 2020-10-30T04:00:00Z Content type: tutorial Language: en Sources: [The Gradle Blog]() Topics: [Gradle](), [Java](), [toolchains](), [configuration](), [Testing](), [Code]() Tags: [build](), [compilation](), [configuration](), [gradle](), [how-to](), [install](), [installation](), [java](), [jdk](), [project](), [run](), [test](), [testing](), [toolchains]() ### AI overview This article introduces Java toolchain support in Gradle 6.7. It explains how to declare a project's required Java version in one place so Gradle can use that version for compilation, testing, documentation, and application execution, while allowing Gradle itself to run with another installed Java version. Gradle can detect suitable JDK installations and download a required JDK when necessary. ### Source excerpt Building a Java project and running Gradle both require the installation of a JDK. Most Gradle users conveniently use the Java installation that is running Gradle to build and test their application. While this is acceptable in simple cases, there are a number of issues with this approach. For example, if a build requires the same Java version to be used on all machines, each developer needs to know about that requirement and install that version manually. It has been possible to configure Gradle to build a project with a different Java version than the one used to run Gradle. However, it has required configuring each task like compilation, test, and javadoc separately. Gradle 6.7 introduces "Java toolchain support". In a nutshell, it allows you to run Gradle with whatever version of Java you have installed, while Gradle builds the project with the version of Java declared in a single place. Gradle will automatically configure the build, detect already installed JDKs and download the required JDK if it is not already installed. No more release or sourceCompatibility tweaks, no more wiki pages describing which JDK you should install for the build to work. The advantages are tremendous, let's see how to use this! Introducing Java toolchains support Java toolchains support enables build authors to declare which Java version their project requires for compiling, testing and running their code. Project wide configuration Let's start with what you, as a build author, need to do, at the minimum: plugins { id("java-library") // or id("application") } java { toolchain { languageVersion.set(JavaLanguageVersion.of(11)) } } And that's it! What do you get with the above in Gradle 6.7? You get: All Java compilation tasks will use Java 11 to build. That means code in the main and test source sets, but also Java code in any custom source set you add, will be built with the configured Java version. All tests tasks, including the default test task and any additional custom Test task, ## Cross-compiling with musl Toolchains DevFeed: [Cross-compiling with musl Toolchains]() Original publisher: [Read original article]() Published: 2020-06-22T12:37:59Z Content type: tutorial Language: en Sources: [Ariya Hidayat]() Topics: [Cross-Compilation](), [toolchains](), [Linux](), [Zig](), [C](), [qemu](), [ci](), [make]() Tags: [c](), [compiler](), [continuous-integration](), [cross-compilation](), [docker](), [linux](), [make](), [mips](), [qemu](), [toolchains](), [windows](), [x86]() ### AI overview A tutorial on using static musl-based toolchains to cross-compile command-line programs for multiple targets, including MIPS and Windows, from a Linux x86-64 host. It also covers testing non-native binaries with QEMU and migrating FastLZ continuous integration to musl.cc. ### Source excerpt When working on command-line utilities which can be useful for various platforms, from Windows on x86 to Linux on MIPS, the existence of a cross-compilation is highly attractive. A number of different binaries can be constructed conveniently from a single, typically powerful host system.