You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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).
The text was updated successfully, but these errors were encountered:
ZIJ
changed the title
Pass one-time JWT token from the orchestrator to CI instead of DIGGER_TOKEN
JWT token instead of DIGGER_TOKEN and workflow args
Feb 23, 2024
ZIJ
changed the title
JWT token instead of DIGGER_TOKEN and workflow args
Pass JWT token from the orchestrator instead of DIGGER_TOKEN and workflow args
Feb 23, 2024
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 bedigger_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).The text was updated successfully, but these errors were encountered: