The dashboard needs to be secure. The following endpoints need to be verified that they are hardened:

• GET /api/pipelines and GET /api/pipelines/:pid must only expose relevant information.
• GET /api/pipelines/:pid/config and POST /api/pipelines/:pid/config must only be accessible to assignees.
• GET /api/runs/:pid/:rid/log and GET /api/runs/:pid/:rid/archived are accessible only if the pipeline is public or the requester is assigned.
• POST /trigger/:token needs to be widely accessible.

Furthermore, CORS and cookie include needs to be set:

• When running in production, only allow same origin for mode and cookies in fetch.
• Otherwise, allow cross origin requests.

Lastly:

• An instance of the dashboard should be tested against SSLLabs and receive an A+.

The CLI needs to be overhauled to see if it still meets standards. Specifically:

• Decide on usefulness of info subcommands for runners, users and pipelines.
• Remove pipeline run.

The linter needs to be installed using the same rules as the runner.

Runner should no longer have the hostname and domain saved, instead the base URL should be saved.
As such:

• When creating the runner, ask for the URL.
• If the healthcheck for the specified runner URL does not pass, don't create it.
• When running, just use the base URL and don't bother with any protocol.

Currently, Node.js 16 is used in the Docker image. This should be updated to 18, and the functionality should work in 18.

The dashboard should be thoroughly tested. This includes:

• Testing the middleware.
• Testing the running logic.

Update the README. Stick to a short introduction, what Candor is/isn't, and some screenshots. Link to the wiki page for more information.

• Ensure backend dependencies and devDependencies are correct.
• Ensure runner dependencies and devDependencies are correct.

Legal things need to be taken care of.

• The project needs to be licensed under MIT.
• The dashboard about needs to be written.
• The dashboard privacy policy needs to be written.
• The dashboard ToS can go, it is not needed.

Instead of JSON, the pipeline configuration should be YAML. Both formats are relatively interchangeable so this should not pose a problem. Internally, the config should still be stored as JSON, and the runner will also still receive JSON.

The examples need to be reworked slightly:

• Verify that they are correct.
• Convert the JSON to YAML.

There should be the possibility to configure the payload when creating the container.

A JSON config should be provided that is then deep-merged with the configuration Candor creates.
It should be provided as a base64 encoded RUNNER_CONTAINER_CONFIG_B environment variable.

This will allow resource limits, isolated networking, etc. and add great security benefit.

Archives should be accessible from the dashboard.

Currently, logs get overwritten in console by the CLI. Either make these logs persist, or write them to file.

There need to be more tests, specifically:

• Tests for each component (volume, image, container, archive).
• Tests for cleanup (i.e. make one of the components fail and assert cleanup of everything occurs).

Automatic Docker image building:

• When pushing to main, the dashboard and runner should be built, tagged with the short commit hash and published on Docker Hub.
• When making a release, the dashboard and runner should be built, tagged with the short commit hash, release version and latest. and published on Docker Hub.

Currently ^C does not terminate the process. This is probably because both Express and the CLI are listening and need to support proper exit handlers.

• Candor needs a favicon!
• Provide metadata

Restructure the project:

• Move frontend/ and backend/ into dashboard/.
• Use index.ts for backend.
• Update any documentation and rename from CI controller to dashboard.
• Update the flowchart, calling it dashboard there too.

You should update the licence to 2023.

In the paths that use the build ID, accept last as a valid ID that will always refer to the last build.

When the dashboard starts using the Docker image, it performs migrations. These generate spammy NPM logs which are not desired and should be suppressed. If possible, it would be nice to maintain the migration log as migrations.log in the log directory.

Currently, the wiki has a quickstart. This should be split up into installation and configuration sections. At the end of the installation, there should be a reference to the configuration.

The installation section should also contain a security subsection, that covers:

• Running behind a reverse proxy.
• Networking securely with runners.

Currently, only the duration is shown. The time when the run was triggered should also be present.

• Provide documentation for how to run the database.
• Update image for the runner to expose ports.
• Remove bootstrap.

There should be an environment variable that specifies how long each stage is permitted to run: RUNNER_CONTAINER_TIMEOUT. The value should be in seconds.

When the timeout is reached, it will fail the stage and write to the log that the timeout has been exceeded. Then the next steps will, as usual, be skipped.

This consists of two components:

• Modals should have an animation when being opened and closed.
• Loading a single pipeline's information occurs too fast, either a transition is needed her or faux loading time.

These changes should be made to aid with usability and not necessarily cosmetics. My eyes hurt at the moment.