Fake pull request

[Stelios123]

GitHub Metadata

Number	Created On	Created By	Assignees
#5	Jun 08, 2023 08:33:48 UTC	gsaslis	Archimidis

The concourse implementation:

• relies on a pre-downloaded fly CLI from the concourse server that the CI broker has been configured with

with that in place, it has 3 (or maybe 2) roles to fill:

Setup: Create and unpause a pipeline in concourse

• acquires token from concourse with fly login
  • need some kind of mechanism that handles re-authenticating / authentication errors (and re-logins).
• creates pipeline (more on this later)

Trigger jobs

There are 2 alternative approaches we are considering:

• let the broker trigger the jobs (using the fly CLI or concourse HTTP API)
• set up a pipeline in concourse that uses a git resource to watch for events triggering the pipeline. This has the added benefit that we don't need to do the triggering, but we would still need to find out about these events somehow, so we can watch for them later on and update the job status.

Triggering should only trigger the job in concourse without watching for the output. We need to capture the build ID from the output and then add this build ID to a data structure of "patches with pending builds".

Watch for results and update Patch with outcome

In terms of watching for the results, we should create some worker thread pool that:

• looks at pending builds
• for each build, uses some polling policy on the job status endpoint to verify whether the build has finished (whether failed or succeeded)
• once the job has finished, it is time to update the patch with a comment.

In terms of "updating the Patch", we will be adding a simple comment to the Patch for now.

NOTES:

• it might make sense to use the API that the fly CLI and web app uses as opposed to wrapping the fly CLI itself.
• try to maintain flat hierarchy of projects (under which pipelines get created) in concourse to match flat hierarchy in radicle
• we don't want to persist job logs in radicle (can get very messy - very fast)
• we discussed at length about what would be the best way to expose a ci_server-agnostic HTTP API endpoint that can be used by clients (web, etc.) to show job status, etc. Most preferred approach for the time being is to have the radicle-ci-broker write to an sqlite database the information about pending jobs and for radicle-httpd to read from that (with an added benefit that the rad cli could then read that information and incorporate that into the Terminal User Interface (TUI).