-
Notifications
You must be signed in to change notification settings - Fork 377
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
ci: upload gem from GitLab release stage #4322
base: master
Are you sure you want to change the base?
Conversation
Thank you for updating Change log entry section 👏 Visited at: 2025-01-24 15:43:14 UTC |
Datadog ReportBranch report: ✅ 0 Failed, 22100 Passed, 1476 Skipped, 5m 15.55s Total Time |
BenchmarksBenchmark execution time: 2025-01-24 16:00:20 Comparing candidate commit 3c293b6 in PR branch Found 0 performance improvements and 0 performance regressions! Performance is the same for 31 metrics, 2 unstable metrics. |
Co-authored-by: Marco Costa <[email protected]>
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #4322 +/- ##
==========================================
- Coverage 97.72% 97.71% -0.01%
==========================================
Files 1365 1365
Lines 82780 82780
Branches 4206 4206
==========================================
- Hits 80897 80889 -8
- Misses 1883 1891 +8 ☔ View full report in Codecov by Sentry. |
What does this PR do?
Automates Ruby gem publishing by uploading from GitLab pipeline.
Motivation:
Remove manual step of uploading the gem on release.
Change log entry
None.
Additional Notes:
This is modeled after the dd-trace-java and dd-trace-py processes which assume that a Git tag/GitHub Release are created first (that is the trigger to "do a release"). Rather than existing Ruby process which first builds/checks tests, then uploads the Gem, and then finally creates the GitHub Release. We can adjust this workflow, but wanted to give us a place to start, aligning with others was simplest.
Since this is done in a final release stage, it does mean that the GitLab pipeline needs to fully run and complete before the Gem will be uploaded. Any checks/tests added to GitLab will become a blocker to the Gem being uploaded.
This process also uses the built Gem that we already do in the pipeline and use in the OCI/lib-injection artifacts.
We have not added any additional checks on GitHub commit status, we can/should do that. I'd love to add to the one pipeline so it is implemented consistently for all repos.
I have not yet added the necessary RubyGem token to the process.
How to test the change?