Skip to main content

WebApp Introduction

Dashboard and side navigation#

Upon logging in, you will see the Dashboard, showing you the status of pipelines of recently run projects. On the dashboard we will all see useful stats and figures, for example current usages and total team storage used.

The side navigation allows you to visit the following web application pages: Pipelines: Allows you to see all projects associated with your organization and set up new projects. Nodes: Artifacts: Artifacts are files that have been generated by a job and is kept after the workflow has completed. These files are used for long-term storage and help provide a single file source for all your team. Artifacts may also be uploaded for use in jobs. For example, board files may be uploaded to build for that particular builds.

dashboard

Pipelines#

Pipelines associated with your organization will appear on the pipeline’s page. Setting up a project will add it to your dashboard and pipelines page. Deleting a project will remove it from your dashboard. From this view we can also see a top level log of the pipeline and have the option to delte the pipeline.

pipelinepage

### Workflows

Workflows are the building blocks for the project. A pipeline can have many workflows for example a main branch and then a local branch. This page shows the status of the separate workflows. and gives a run history. From here we can also view the top level log of the workflow, stop the workflow, see when it was last run and how long that run was. Users can also see the commit id so this can be traced back to who wrote the code for the last commit.

workflows

jobs that make up a workflow#

Jobs are distinct set of steps that are to be run as part of the pipeline. They are also used to define the runner that will be used to execute these tasks. Each job is defined in the config.yaml file. From the Jobs page we get a lot of useful information. We can see the status of the jobs when they were last run and how long they were run for. We also get information about the usage of the jobs and how many artifacts are used.

jobs

Inside the job#

A job is specified by the user in the config file in their git repository. It will run a series of commands and tests that are specified by the user. From this page we can see the steps in the job and we can see the output from thse steps by clicking on each step. On this page we also get further info about the job, the time taken to run and last time it was run. if the job i currently running we are also provided with its current staus and the usage.

job

Nodes#

A node is a machine (physical or virtual) machine that is in the cluster. The status says whether the node is ready to accept jobs -- if it is ready, all is well. If it is not ready, then either it is just switched off, starting up, or something i wrong with it. Nodes in a cluster can have certain roles. e.g. Control plane / master (same thing), or a worker node. the worker nodes merely run jobs. While control plane and master nodes run system processes and they can also optionally run jobs. CPU is the number of CPU cores that the node offers to the cluster. There are two memory parameters: Capacity is the total memory on the node. The Add node button generates a shell script. when you run the shell script on a machine that is not part of the cluster, the node will join the cluster.

nodes

Artifact Store#

The artifact store provides long-term storage for artifacts. Artifacts are files or folders that have been produce by workflows or uploaded by users. The artifact store means users can download files once a workflow has finished and upload files for use in workflows.

artifactstore

Organization settings#

BeetleboxCI supports multi-tenancy, which allows multiple organisations or departments to share the same cluster and allows separation between their projects. This way, each organisation or department can have their own set of projects on a single cluster, and these will not interfere with each other.