Description
Why do we even need DIGGER_TOKEN? Why not just use GitHub app as-is, without additional digger auth on top?
The reason we built it this way was to enable Digger CLI to authenticate with the orchestrator. But since the orchestrator is the one starting the jobs, and it in turn needs to be authenticated with the CI to start these jobs (via Github App installation on Github, or webhooks with other CI systems) - we can easily pass a one-time JWT token when triggering each job so that it can send authenticated requests to the orchestrator.
We can also store all other required metadata (like comment_id) in that JWT token. Then the only workflow argument we'd need would be digger_token, everything else will be read by the CLI from the token.
Proposed implementation
Easiest way to achieve this without breaking older versions would be to check for digger_token argument in the CLI, and if it's set, export the DIGGER_TOKEN env var. The orchestrator needs to generate a short-lived token for each job (not batch) and store it in the database. Then it also needs to accept such tokens in addition to Frontegg tokens (or should we remove Frontegg altogether? This might also solve #1074).