Phil Dibowitz

@usvi - there's no reason to fork, PRs here will do just fine. And now that @dequis has sent you invites, you can simply make a branch here for your...

@DMJC - NICE! Can you make a PR against this repo from your fork, then people can collaborate on it? @dequis offered to give input/guidance to anyone working on it,...

Uh, what? Your code and your docs disagree with you: https://github.com/danger/danger/blob/d9fff7cbed6b0a4bfb6465709d0352e700bdd00e/lib/danger/ci_source/github_actions.rb#L4 The danger.system website says your support is and pulls from there for the how to.

No, we are not (well, we don't specify, and my understanding is the default is `false`)

... there's no setup-ruby step required when using the built-in Action, it handles that itself. As I said, see: https://github.com/danger/danger/blob/d9fff7cbed6b0a4bfb6465709d0352e700bdd00e/lib/danger/ci_source/github_actions.rb#L4

I filed a bug against chef on this, I'll find it when I'm not on mobile. There was a work around I'll find you as well... Internally we're still on...

Hmm, this isn't the issue I was thinking of... this is odd. It looks like rugged gets compiled against the openssl headers/libs on your system, not the ones in your...

You'll want to clean up all the cruft in your chef-server install. I'll repro the chefdk part and get back to you soon!

I can confirm a repro of this on Debian with chefdk2, chefdk3, rugged 0.26 and rugged 0.27. My suspicion is that this is debian/ubuntu-specific, but I'll continue to debug. I'm...

Yeah rugged is getting compiled wrong. The system one has it: ``` [phild@fuel lib]$ objdump -T /usr/lib/x86_64-linux-gnu/libssl.so.1.1 | grep init_ssl 0000000000035ca0 g DF .text 000000000000010e OPENSSL_1_1_0 OPENSSL_init_ssl ``` But the...