Commit cf5fff8
Add 3.4-asan builds, try 2
**What does this PR do?**
This PR is a second attempt at adding 3.4-asan builds (first attempt was
#13); this version
is now atop #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 #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 #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.1343171 parent 634d2f6 commit cf5fff8
1 file changed
+20
-4
lines changed| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
19 | 19 | | |
20 | 20 | | |
21 | 21 | | |
| 22 | + | |
22 | 23 | | |
23 | 24 | | |
24 | 25 | | |
| |||
28 | 29 | | |
29 | 30 | | |
30 | 31 | | |
| 32 | + | |
31 | 33 | | |
32 | 34 | | |
33 | 35 | | |
34 | 36 | | |
35 | | - | |
| 37 | + | |
| 38 | + | |
| 39 | + | |
| 40 | + | |
| 41 | + | |
| 42 | + | |
36 | 43 | | |
37 | 44 | | |
38 | 45 | | |
39 | 46 | | |
40 | 47 | | |
41 | 48 | | |
| 49 | + | |
42 | 50 | | |
43 | 51 | | |
44 | 52 | | |
45 | 53 | | |
46 | 54 | | |
47 | 55 | | |
| 56 | + | |
48 | 57 | | |
49 | 58 | | |
50 | 59 | | |
| |||
56 | 65 | | |
57 | 66 | | |
58 | 67 | | |
59 | | - | |
| 68 | + | |
60 | 69 | | |
61 | 70 | | |
62 | 71 | | |
63 | 72 | | |
64 | 73 | | |
65 | 74 | | |
66 | | - | |
| 75 | + | |
67 | 76 | | |
68 | 77 | | |
69 | 78 | | |
| |||
116 | 125 | | |
117 | 126 | | |
118 | 127 | | |
| 128 | + | |
| 129 | + | |
| 130 | + | |
| 131 | + | |
| 132 | + | |
| 133 | + | |
| 134 | + | |
119 | 135 | | |
120 | 136 | | |
121 | 137 | | |
| |||
191 | 207 | | |
192 | 208 | | |
193 | 209 | | |
194 | | - | |
| 210 | + | |
195 | 211 | | |
196 | 212 | | |
197 | 213 | | |
| |||
0 commit comments