issue-link js-issue-link" data-error-text="Failed to load title" data-id="2795255472" data-permission-text="Title is private" data-url="https://github.com/ruby/ruby-dev-builder/issues/13" data-hovercard-type="pull_request" data-hovercard-url="/ruby/ruby-dev-builder/pull/13/hovercard" href="https://github.com/ruby/ruby-dev-builder/pull/13">ruby#13); this version is now atop ruby#14 . It introduces a new "3.4-asan" build, based on the existing asan builds, but just pointed at the `ruby_3_4` branch. In ruby#13, we were building the latest tagged 3.4 release, which I expect would be more stable than just using `ruby_3_4` (and thus better for my downstream purposes of "having a build that doesn't fail for non-asan-related reasons"). Switching between both options is as simple as: ```diff diff --git a/.github/workflows/build.yml b/.github/workflows/build.yml index 7eb72a8..d7608d9 100644 --- a/.github/workflows/build.yml +++ b/.github/workflows/build.yml @@ -29,6 +29,8 @@ jobs: with: repository: ruby/ruby path: ruby + fetch-tags: true fetch-depth: 0 - name: Set latest_commit id: latest_commit working-directory: ruby @@ -37,7 +39,8 @@ jobs: id: latest_commit_3_4_asan working-directory: ruby run: | - git checkout ruby_3_4 + LATEST_TAG=$(git tag --list | grep -E "v3_4_[0-9]+$" | sort -V | tail -n1) + git checkout "$LATEST_TAG" echo "commit=$(git rev-parse HEAD)" >> $GITHUB_OUTPUT - name: Check if latest commit already built uses: actions/github-script@v7 ``` I personally prefer building from the tag, but happy to use the branch option if that's preferrable. **Motivation:** The intention of "3.4-stable" is to provide the latest up-to-date stable Ruby, so that we can reliably use it as a breaking CI step. As discussed in ruby/setup-ruby#682, the current ruby-asan builds are a bit of a "sharp edge" when used in CI because they may break due to changes that are completely unrelated to asan. Building asan rubies is a bit awkward still, as e.g. ruby-build and other version managers don't have support for it, and it requires very modern versions of specific system tools (e.g. clang). **Additional Notes:** In particular, I decided to not touch the logic that determines weather there's a more recent commit to build or not. This does mean that if ruby master sees no commits, but there's changes in the 3.4 branch, this won't be picked up immediately; and it also means that if there's a new master commit and no change to the 3.4 branch we still rebuild 3.4-asan. My thinking is that given that ruby#14 added caching already, this approach keeps things simple. Let me know if you're not convinced, and I can change that. **How to test the change?** I've built this in the downstream fork, and manually downloaded the resulting Ruby and it seems to be in good shape and with asan working fine. * Successful run: https://github.com/DataDog/ruby-dev-builder/actions/runs/13371638547 * Resulting builds: https://github.com/DataDog/ruby-dev-builder/releases/tag/v20250217.134317

Commits

Commits on Feb 17, 2025

Add 3.4-asan builds, try 2

Commits on Feb 18, 2025

Minor: Fix casing of "ASan"

Combine clone steps for asan and master

Build 3.4-asan from latest stable tag, not latest 3.4 branch

Avoid getting full history when getting tags