Get openssl from Nix if not available in path

[JakeHillion]

nix-develop-gha.sh depends on several bash builtins, nix, and openssl. If run on a self-hosted runner on NixOS openssl isn't available in PATH by default and the action fails. This change checks whether openssl is present in path and uses it, or otherwise gets it from nix build which we already depend on, without polluting PATH.

Test plan:

• Tested on a self-hosted runner with only nix available. Failed before, works after.
• Tested on a GitHub hosted runner. Worked before, works after.

[tomasbarton-stemcell]

I also ran into this issue. The patch provided by @JakeHillion in this PR works 🥳

[nicknovitski]

This repository is also a flake, and its default package includes openssl and the other dependencies of the action. On "minimalist" runners like yours, you should be able to do this:

  - run: nix run github:nicknovitski/nix-develop/v1

You can also add this repository as an input to your flakes, if you want more control over the package versions used. The readme includes an example of this.

Do either of those approaches work for you two?

[JakeHillion]

  - run: nix run github:nicknovitski/nix-develop/v1

Thanks for the response! I did catch this in the README after submitting this PR, and I expect it probably would work.

I still want to propose this change. It's kind of a stupid reason, but I think in certain repositories/communities there's an inherent opposition to using Nix, where it's often called complicated. For some reason, people don't seem to think this about random GitHub Actions being used.

A second reason is that it's quite easy to pin the version of a GHA and update it with tools like Renovate, while to do this with Nix I'd have to add the action as an input to my flake and run it in quite a convoluted way.

All in all they're pretty small papercuts and the nix run option is a good backup. I think this change makes it a little bit easier for people to get started, but it's your call!

[tomasbarton-stemcell]

Do either of those approaches work for you two?

Yeah, this is good for me. Especially with the updates you did to the readme yesterday. Now it is clear that your action has some system dependencies while also providing a solution for when they are missing 👍🏻

On the other hand I also agree with Jake: if it is simple to make this work transparently, as in being more aligned with the standard uses: ... then I think it is worth considering.