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.

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

[PROF-9368] Revert Ruby 2.1/2.2/2.3 CI images to older Debian to support mysql gem #3542

Merged
merged 1 commit into from
Mar 20, 2024

Conversation

ivoanjo
Copy link
Member

@ivoanjo ivoanjo commented Mar 20, 2024

What does this PR do?

This PR is a slightly tweaked revert of
#3534 .

TL;DR after updating our Ruby 2.1/2.2/2.3 images to a newer debian, we discovered that some of our CI testing requires the mysql gem, which breaks on newer Debian versions (due to a newer libmysqlclient/libmariadb).

With these reverts, I was able to locally rebuild the images and install both mysql and nokogiri:

$ docker run -ti -v `pwd`:/working ivoanjo/docker-library:ddtrace_rb_2_3_8_testing_t6  /bin/bash
root@255fe2dc2374:/app# ruby -v
ruby 2.3.8p459 (2018-10-18 revision 65136) [x86_64-linux]
root@255fe2dc2374:/app# docker-compose -v
docker-compose version 1.8.0, build unknown
root@255fe2dc2374:/app# bundle -v
Bundler version 1.17.3
root@255fe2dc2374:/app# gem install mysql
Fetching mysql-2.9.1.gem
Building native extensions. This could take a while...
Successfully installed mysql-2.9.1
1 gem installed
root@255fe2dc2374:/app# gem install nokogiri -v '= 1.10.10'
Fetching nokogiri-1.10.10.gem
Fetching mini_portile2-2.4.0.gem
Successfully installed mini_portile2-2.4.0
Building native extensions. This could take a while...
Successfully installed nokogiri-1.10.10
2 gems installed

I was able to reproduce similar successful output on 2.1 and 2.2 as well (using nokogiri 1.9.1; 1.10.10 requires 2.3).

Additional Notes:

In the Dockerfile that #3534 initially changed there was a comment stating that we were installing docker-compose 1.21 from stretch-backports, which confused me initially, since I couldn't install that version from backports.

I checked an image build log from 2 months ago
(https://github.com/DataDog/dd-trace-rb/actions/runs/7386478002/job/20093153619) and copied its image sha
ghcr.io/datadog/dd-trace-rb/ruby:2.3.8-dd@sha256:b940776f41a5993e728f813c92734eaa82070ba74626ad8d2768a0242de269b3 and got the same docker-compose 1.8.0 I'm getting now:

$ docker run -ti -v `pwd`:/working ghcr.io/datadog/dd-trace-rb/ruby:2.3.8-dd@sha256:b940776f41a5993e728f813c92734eaa82070ba74626ad8d2768a0242de269b3 /bin/bash
root@23481c358c5b:/app# docker-compose -v
docker-compose version 1.8.0, build unknown

Unless I'm doing something wrong, either this comment was never correct OR somehow the package we were using got purged.

Either way, it seems to me that this indicates we can still use this version, so let's move forward (and hope to really stop supporting these Rubies soon).

How to test the change?

Check CI builds for the images and/or build locally. Note that our overall CI is a bit undisposed with incorrect images, so I'm expecting red unrelated CI jobs that will only be fixed after we publish these new images.

For Datadog employees:

  • If this PR touches code that signs or publishes builds or packages, or handles
    credentials of any kind, I've requested a review from @DataDog/security-design-and-guidance.
  • This PR doesn't touch any of that.

…ort mysql gem

**What does this PR do?**

This PR is a slightly tweaked revert of
#3534 .

TL;DR after updating our Ruby 2.1/2.2/2.3 images to a newer debian,
we discovered that some of our CI testing requires the `mysql` gem,
which breaks on newer Debian versions (due to a newer
libmysqlclient/libmariadb).

With these reverts, I was able to locally rebuild the images and install
both mysql and nokogiri:

```
$ docker run -ti -v `pwd`:/working ivoanjo/docker-library:ddtrace_rb_2_3_8_testing_t6  /bin/bash
root@255fe2dc2374:/app# ruby -v
ruby 2.3.8p459 (2018-10-18 revision 65136) [x86_64-linux]
root@255fe2dc2374:/app# docker-compose -v
docker-compose version 1.8.0, build unknown
root@255fe2dc2374:/app# bundle -v
Bundler version 1.17.3
root@255fe2dc2374:/app# gem install mysql
Fetching mysql-2.9.1.gem
Building native extensions. This could take a while...
Successfully installed mysql-2.9.1
1 gem installed
root@255fe2dc2374:/app# gem install nokogiri -v '= 1.10.10'
Fetching nokogiri-1.10.10.gem
Fetching mini_portile2-2.4.0.gem
Successfully installed mini_portile2-2.4.0
Building native extensions. This could take a while...
Successfully installed nokogiri-1.10.10
2 gems installed
```

I was able to reproduce similar successful output on 2.1 and 2.2
as well (using nokogiri 1.9.1; 1.10.10 requires 2.3).

**Motivation:**

**Additional Notes:**

In the `Dockerfile` that #3534 initially changed there was a comment
stating that we were installing `docker-compose 1.21` from
stretch-backports, which confused me initially, since I couldn't
install that version from backports.

I checked an image build log from 2 months ago
(https://github.com/DataDog/dd-trace-rb/actions/runs/7386478002/job/20093153619)
and copied its image sha
`ghcr.io/datadog/dd-trace-rb/ruby:2.3.8-dd@sha256:b940776f41a5993e728f813c92734eaa82070ba74626ad8d2768a0242de269b3`
and got the same `docker-compose 1.8.0` I'm getting now:

```
$ docker run -ti -v `pwd`:/working ghcr.io/datadog/dd-trace-rb/ruby:2.3.8-dd@sha256:b940776f41a5993e728f813c92734eaa82070ba74626ad8d2768a0242de269b3 /bin/bash
root@23481c358c5b:/app# docker-compose -v
docker-compose version 1.8.0, build unknown
```

Unless I'm doing something wrong, either this comment was
never correct OR somehow the package we were using got purged.

Either way, it seems to me that this indicates we can still
use this version, so let's move forward (and hope to really
stop supporting these Rubies soon).

**How to test the change?**

Check CI builds for the images and/or build locally. Note that
our overall CI is a bit undisposed with incorrect images, so I'm
expecting red unrelated CI jobs that will only be fixed after we
publish these new images.
@ivoanjo ivoanjo requested a review from a team as a code owner March 20, 2024 14:06
@github-actions github-actions bot added the dev/ci Involves CircleCI, GitHub Actions, or GitLab label Mar 20, 2024
@ivoanjo ivoanjo force-pushed the ivoanjo/revert-ci-images-to-debian-stretch branch from cae8d8d to 2119ba1 Compare March 20, 2024 14:06
@ivoanjo ivoanjo added this to the 1.21.1 milestone Mar 20, 2024
Copy link
Contributor

@AlexJF AlexJF left a comment

Choose a reason for hiding this comment

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

LGTM and 💯 on the here be dragons warnings. Lets potentially save someone some pain in the future 😂

@ivoanjo
Copy link
Member Author

ivoanjo commented Mar 20, 2024

Image builds worked, going ahead and merging this (ignore other CI failures, see notes for why).

@ivoanjo ivoanjo merged commit 9d19758 into master Mar 20, 2024
214 of 218 checks passed
@ivoanjo ivoanjo deleted the ivoanjo/revert-ci-images-to-debian-stretch branch March 20, 2024 15:07
@lloeki lloeki mentioned this pull request Mar 20, 2024
9 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
dev/ci Involves CircleCI, GitHub Actions, or GitLab
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants