Feature: `github` executor fallback to HTTP if `gh` is not installed

[DanielNetzer]

Due to the fact that GH CLI is fairly new and almost doesn't exist on CI/CD agents. might be trivial to use the same cmd line interface as the version package to reduce the need for multiple CLI's that do pretty much the same thing, or as a counter suggestion, might be worth considering the creation of a semver:git that will work with the git CLI.

[edbzn]

Hi @DanielNetzer, the GitHub executor aims to create releases on the GitHub platform, and as far as I know, we have to use either the GitHub API via HTTP or the gh CLI (which is easier) in order to create the release. It is not possible just using Git, or maybe I'm missing something with your suggestion.

[DanielNetzer]

@edbzn you are correct, I wasn't aware of that. Maybe we can add it as another executor and use the API instead of GH new cli, following the reasoning I wrote above. WDYT? would you consider a PR for that?

[edbzn]

I'm not sure it's worth re-developing an executor, why don't you manually provide the gh CLI in your CI release job?

[DanielNetzer]

Since we don't do the pipeline in dockers, we will need to install on all the agents image the GH cli, our agents are based on K8S cluster for Azure DevOps that we self host, if I'll add a step to install the GH cli on the pipeline it will slow the CI in a monorepo containing over 16 projects with 12 developers working on it.

While utilizing an http endpoint instead of the GH cli will work out of the box and will do the exact same thing. maybe we can add to the same executor a check if the GH cli exists, it will use it and if not it will resort to using the GITHUB HTTP request.

WDYT?

[edbzn]

I agree that we could provide an HTTP fallback if the CLI is not installed.