-
Notifications
You must be signed in to change notification settings - Fork 2
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
Move CI to GHA; update supported Ruby, ddtrace, Redis versions [DEM-331] #72
Conversation
5260b41
to
0ae0d14
Compare
f4b4219
to
fd38f2e
Compare
.github/workflows/ci.yml
Outdated
postgres: [ '12', '13', '14', '15', '16' ] | ||
redis: [ '6', '7' ] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Curious if you think we need to test all the PG and Redis versions. I don't think we were before. Are we using anything beyond normal PG queries or Redis commands? Either way I think we can probably drop PG 12 and 13 at least, since the monolith along with other projects being on 14 now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tbh this is almost certainly overkill; I was on a bit of a "Test All The Things" spree yesterday, given how many weird version issues we ran into with moving this project to GHA in the first place, but you make a good point re: redis and postgres queries
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think I will tell the CI workflow to use latest
of each and that way we'll see on any new PR if something breaks when one of the images gets updates
CHANGELOG.md
Outdated
@@ -1,6 +1,10 @@ | |||
# sidekiq_publisher | |||
|
|||
## (Unreleased) | |||
## (unreleased; 3.0.0) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we have to change this after we push out the actual release? Just curious why we're labeling this as "unreleased"?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was planning to one final update to this PR to remove that -- good question
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I may as well do that now!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just one question, but everything looks good to me! Thanks for tackling this!
What did we change?
2.6
and2.7
as they are past end of lifeddtrace <= 1.8.0
5.x
Why are we doing this?
Moving to Github workflows for CI unearthed a number of incompatibilities across versions of ruby, ddtrace, and redis. As some of these were past EOL, we (Demand Scalability team) decided to drop support for them and prepare to release a new gem version as well.
I've also added testing through Redis 7 and Postgres 16, as this did not need any additional changes and ensures the gem will be tested against the most recent versions of both.
How was it tested?