From 806f5c453a1be12ec3d235a5c8fbb26f876762fa Mon Sep 17 00:00:00 2001 From: PE39806 <185931318+PE39806@users.noreply.github.com> Date: Wed, 13 May 2026 15:02:03 +0000 Subject: [PATCH 01/23] Remove legacy v1 docs entirely --- .../getting-started/authentication.mdx | 100 ---- .../building-the-bailo-image.mdx | 21 - .../configuration/app-configuration.mdx | 48 -- .../configuration/making-a-schema.mdx | 222 -------- .../getting-started/helm-deployments.mdx | 63 --- .../isolated-network-deployment.mdx | 39 -- .../administration/migrations/bailo-0.4.mdx | 120 ----- .../administration/migrations/bailo-2.0.mdx | 26 - .../pages/docs/v1/developers/contributing.mdx | 41 -- .../pages/docs/v1/developers/dev-notes.mdx | 23 - .../pages/docs/v1/developers/dev-setup.mdx | 50 -- .../main-concepts/building-models.mdx | 139 ----- .../developers/main-concepts/logical-flow.mdx | 28 - .../processes/adding-an-endpoint.mdx | 78 --- .../v1/developers/testing/e2e-testing.mdx | 108 ---- .../v1/developers/testing/manual-testing.mdx | 28 - .../v1/developers/testing/unit-testing.mdx | 56 -- .../docs/v1/developers/useful-commands.mdx | 105 ---- frontend/pages/docs/v1/directory.tsx | 138 ----- .../docs/v1/errors/duplicate-version.mdx | 14 - frontend/pages/docs/v1/index.mdx | 70 --- .../pages/docs/v1/users/approvals/index.mdx | 50 -- .../v1/users/automation/key-workflows.mdx | 56 -- .../v1/users/automation/python-client.mdx | 181 ------- .../automation/workflows/create-a-model.mdx | 75 --- .../automation/workflows/edit-model-card.mdx | 63 --- .../workflows/upload-new-version.mdx | 122 ----- .../docs/v1/users/deployments/compliance.mdx | 36 -- .../deployments/requesting-a-deployment.mdx | 31 -- .../deployments/using-a-deployment/docker.mdx | 60 --- .../pages/docs/v1/users/marketplace/index.mdx | 17 - .../v1/users/upload-a-model/model-wrapper.mdx | 480 ------------------ .../upload-a-model/preparing-the-code.mdx | 196 ------- .../v1/users/upload-a-model/requirements.mdx | 22 - .../users/upload-a-model/updating-a-model.mdx | 16 - .../users/upload-a-model/upload-to-bailo.mdx | 42 -- .../upload-a-model/why-upload-a-model.mdx | 51 -- 37 files changed, 3015 deletions(-) delete mode 100644 frontend/pages/docs/v1/administration/getting-started/authentication.mdx delete mode 100644 frontend/pages/docs/v1/administration/getting-started/building-the-bailo-image.mdx delete mode 100644 frontend/pages/docs/v1/administration/getting-started/configuration/app-configuration.mdx delete mode 100644 frontend/pages/docs/v1/administration/getting-started/configuration/making-a-schema.mdx delete mode 100644 frontend/pages/docs/v1/administration/getting-started/helm-deployments.mdx delete mode 100644 frontend/pages/docs/v1/administration/getting-started/isolated-network-deployment.mdx delete mode 100644 frontend/pages/docs/v1/administration/migrations/bailo-0.4.mdx delete mode 100644 frontend/pages/docs/v1/administration/migrations/bailo-2.0.mdx delete mode 100644 frontend/pages/docs/v1/developers/contributing.mdx delete mode 100644 frontend/pages/docs/v1/developers/dev-notes.mdx delete mode 100644 frontend/pages/docs/v1/developers/dev-setup.mdx delete mode 100644 frontend/pages/docs/v1/developers/main-concepts/building-models.mdx delete mode 100644 frontend/pages/docs/v1/developers/main-concepts/logical-flow.mdx delete mode 100644 frontend/pages/docs/v1/developers/processes/adding-an-endpoint.mdx delete mode 100644 frontend/pages/docs/v1/developers/testing/e2e-testing.mdx delete mode 100644 frontend/pages/docs/v1/developers/testing/manual-testing.mdx delete mode 100644 frontend/pages/docs/v1/developers/testing/unit-testing.mdx delete mode 100644 frontend/pages/docs/v1/developers/useful-commands.mdx delete mode 100644 frontend/pages/docs/v1/directory.tsx delete mode 100644 frontend/pages/docs/v1/errors/duplicate-version.mdx delete mode 100644 frontend/pages/docs/v1/index.mdx delete mode 100644 frontend/pages/docs/v1/users/approvals/index.mdx delete mode 100644 frontend/pages/docs/v1/users/automation/key-workflows.mdx delete mode 100644 frontend/pages/docs/v1/users/automation/python-client.mdx delete mode 100644 frontend/pages/docs/v1/users/automation/workflows/create-a-model.mdx delete mode 100644 frontend/pages/docs/v1/users/automation/workflows/edit-model-card.mdx delete mode 100644 frontend/pages/docs/v1/users/automation/workflows/upload-new-version.mdx delete mode 100644 frontend/pages/docs/v1/users/deployments/compliance.mdx delete mode 100644 frontend/pages/docs/v1/users/deployments/requesting-a-deployment.mdx delete mode 100644 frontend/pages/docs/v1/users/deployments/using-a-deployment/docker.mdx delete mode 100644 frontend/pages/docs/v1/users/marketplace/index.mdx delete mode 100644 frontend/pages/docs/v1/users/upload-a-model/model-wrapper.mdx delete mode 100644 frontend/pages/docs/v1/users/upload-a-model/preparing-the-code.mdx delete mode 100644 frontend/pages/docs/v1/users/upload-a-model/requirements.mdx delete mode 100644 frontend/pages/docs/v1/users/upload-a-model/updating-a-model.mdx delete mode 100644 frontend/pages/docs/v1/users/upload-a-model/upload-to-bailo.mdx delete mode 100644 frontend/pages/docs/v1/users/upload-a-model/why-upload-a-model.mdx diff --git a/frontend/pages/docs/v1/administration/getting-started/authentication.mdx b/frontend/pages/docs/v1/administration/getting-started/authentication.mdx deleted file mode 100644 index b7f161dc9b..0000000000 --- a/frontend/pages/docs/v1/administration/getting-started/authentication.mdx +++ /dev/null @@ -1,100 +0,0 @@ -import DocsWrapper from 'src/docs/DocsWrapper' - -# Authentication - -Bailo is intended to be run in multiple different environments, each of which will have their own standard -authentication and authorisation methods. To enable this, Bailo exposes a class of methods that can be overridden to -integrate with various services. - -By default, we expect the Bailo instance to be run behind a reverse proxy, which sets the following headers to identify -users and their roles: - -- `x-userid` is a unique identifier for a user. -- `x-email` is an optional email address (to send notifications). -- `x-user` is a JSON encoded object containing any other user data. - -Within Nginx, these can be set via the `proxy_set_header` declaration: - -```bash -proxy_set_header X-UserId "user"; -proxy_set_header X-Email "user@example.com"; -proxy_set_header X-User '{"some":"data"}'; -``` - -To support other authentication mechanisms, an administrator can override the `getUserFromReq` method to get this -information from any other method. To do this edit `backend/src/connectors/Authorisation.ts` to override the required -methods from `backend/src/utils/AuthorisationBase.ts`. E.g. - -```javascript -// backend/src/connectors/Authorisation.ts -import AuthorisationBase from '../utils/AuthorisationBase.js' -import { Request } from 'express' - -class Authorisation extends AuthorisationBase { - async getUserFromReq(_req: Request) { - const username = req.get('x-username') - - return { - userId: username, - email: await getUserEmail(username), - data: await getUserData(username), - } - } -} - -export default Authorisation -``` - -In the above example, instead of getting this data from headers passed into the application, we now get the username -from headers and get the users email and data from another method. - -This is called on each request and not cached, so you may want to implement this yourself if you are using expensive -cryptographic functions or making external network requests. - -# Authorisation - -By default Bailo protects models from deployment by requiring an approval by the model owner. Also, only the model owner -is capable of editting a model that has been uploaded. All users can view all models uploaded to the system. - -This is unlikely to be suitable for large organisations, who may wish to integrate their own internal authorisation -system into Bailo. An administrator can integrate with their internal authorisation system by overriding one of the -`canUserSeeX` functions, visible in `backend/src/utils/AuthorisationBase.ts`. Each functino takes in a user object, as -well as the object to view. The function is then expected to return either `true` or `false` depending on if the user -can view that object. - -This authorisation affects both users directly viewing a model, as well as the models visible in the marketplace. - -An example authorisation implemention: - -```javascript -// backend/src/connectors/Authorisation.ts -import AuthorisationBase from '../utils/AuthorisationBase.js' -import { UserInterface } from '../models/User.js' -import { VersionDoc } from '../models/Version.js' - -class Authorisation extends AuthorisationBase { - async getUserFromReq(_req: Request) { - // we now include roles in the user object - return { - userId: 'user', - data: { roles: ['alpha', 'beta', 'gamma'] }, - } - } - - async canUserSeeVersion(user: UserInterface, model: VersionDoc) { - // we can access the roles from the user document - const userRoles = user.data.roles - // our schema has a 'role' field we need users to have to see it - const versionRole = version.metadata.authorisation.role - - // check if the user has the required role - const canAccess = userRoles.includes(versionRole)) - - return canAccess - } -} - -export default Authorisation -``` - -export default ({ children }) => {children} diff --git a/frontend/pages/docs/v1/administration/getting-started/building-the-bailo-image.mdx b/frontend/pages/docs/v1/administration/getting-started/building-the-bailo-image.mdx deleted file mode 100644 index 45cb0f1660..0000000000 --- a/frontend/pages/docs/v1/administration/getting-started/building-the-bailo-image.mdx +++ /dev/null @@ -1,21 +0,0 @@ -import DocsWrapper from 'src/docs/DocsWrapper' - -# Building the Bailo Image - -Bailo does not provide pre-built images. Building one yourself is easy! Two images should be produced, one for the -frontend and one for the backend. - -```bash -# Bailo uses a monorepo, so images should be built from the root directory -$ docker build --build-context python=./lib/python -t "bailo-backend" -f ./backend/Dockerfile . -$ docker build -t "bailo-frontend" -f ./frontend/Dockerfile . -$ docker build -t "bailo-artefactscan" -f ./lib/artefactscan_api/Dockerfile . -``` - -Ensure you do not use the development stages in Dockerfiles (used by building with `--target dev`) as they expect the -application to be mounted into them at a later point in time (to enable hot code reloading). - -`docker` can be swapped out for any other OCI compliant container build platform. We routinely test with both `podman` -and `OpenShift Builder`. This image should be pushed to a registry that is accessible from your deployment target. - -export default ({ children }) => {children} diff --git a/frontend/pages/docs/v1/administration/getting-started/configuration/app-configuration.mdx b/frontend/pages/docs/v1/administration/getting-started/configuration/app-configuration.mdx deleted file mode 100644 index 4cc1b7398d..0000000000 --- a/frontend/pages/docs/v1/administration/getting-started/configuration/app-configuration.mdx +++ /dev/null @@ -1,48 +0,0 @@ -import DocsWrapper from 'src/docs/DocsWrapper' - -# App Configuration - -## Configuration Files - -Bailo uses [`node-config`](https://github.com/node-config/node-config#readme) for application configuration. -`node-config` organizes hierarchical configurations, allowing the user to set a series of overides over a base -configuration. - -The default set of configuration can be found in `config/default.js`, with overrides for other environments included in -the same folder. For production environments, configuration should be placed in either `production.cjs` or `local.js` to -override the default configuration. - -The full order of configuration inheritance can be found -[on the node-config wiki](https://github.com/node-config/node-config/wiki/Configuration-Files). - -Given the following set of files: - -```javascript -// default.js -{ a: 5, b: "ten", c: { d: 20, e: 25 } } - -// production.cjs -{ b: 10, c: { d: "d" } } - -// local.js -{ c: { d: 999 } } -``` - -The result is: - -```javascript -{ - a: 5, // no overrides - b: 10, // overridden in production.cjs - c: { - d: 999, // overriden in production.cjs, then again in local.js - e: 25 // not overwritten, objects are merged together. - } -} -``` - -When deploying using `helm`, configuration is primarily handled through `values.yaml` controlling -`helm/bailo/templates/bailo/bailo.configmap.yaml`. Configuration is loaded when the application starts. The application -must be restarted when configuration changes. - -export default ({ children }) => {children} diff --git a/frontend/pages/docs/v1/administration/getting-started/configuration/making-a-schema.mdx b/frontend/pages/docs/v1/administration/getting-started/configuration/making-a-schema.mdx deleted file mode 100644 index 4fdd708d31..0000000000 --- a/frontend/pages/docs/v1/administration/getting-started/configuration/making-a-schema.mdx +++ /dev/null @@ -1,222 +0,0 @@ -import DocsWrapper from 'src/docs/DocsWrapper' - -# Creating and Uploading schemas - -Bailo makes use of the [RJSF](https://react-jsonschema-form.readthedocs.io/en/latest/) (react-jsonschema-form) library -in order to dynamically create its upload & deployment forms. These forms can be constructed of various existing -widgets, or even use custom widgets defined in Bailo. - -## Example / minimal schemas - -Bailo includes both an example schema for uploads and for deployments. You can find them in -`backend/src/scripts/example_schemas`. It is important to note that these schemas contain all of mandatory fields that -the application needs in order to run. These fields are hard-coded in various places in the source code. - -## Create a schema - -### Simple questions - -A typical object inside the schema will look like this: - -```json -"firstName": { - "type": "string", - "title": "First name", - "default": "Chuck", - "description": "This is for your first name" -} -``` - -The type property can be altered depending on what value you want the question to return. The title property will be -displayed as the question itself, and the description will appear under the question to include any additional -information that might help the user. Please note that if you do not include a title property, the library will use the -name of the object (in this case firstName) instead. - -### Dates - -Dates can be added like this: - -```json -"date": { - "type": "string", - "title": "Date of birth", - "format": "date" -} -``` - -### Sections - -When using Bailo you will see that the upload form is made up of a number of pages. Each page is a separate object -inside the first "properties" property of the schema. For example: - -```json -"properties": { - "firstPage": { - "type": "object", - "title": "Page 1", - "properties": { - ... - } - }, - "secondPage": { - "type": "object", - "title": "Page 2", - "properties": { - ... - } - } -} -``` - -Creating sub-sections works identically to how we defined our pages above. If we take the first page of our example -above, and then amend it so it looks like this: - -```json -"properties": { - "firstPage": { - "type": "object", - "title": "Page 1", - "properties": { - "sectionOne": { - "type": "object", - "title": "Section 1" - "properties": { - "questionOne": { - "type": "number", - "title": "Enter a number", - } - } - }, - "sectionTwo": { - "type": "object", - "title": "Section 2" - "properties": { - "questionTwo": { - "type": "string", - "title": "Enter a string", - } - } - } - }, - ... -} -``` - -#### Hiding sections from the model card - -Sections will display on the model card page by default, but in the case whereby a section needs to be hidden from the -model card, then add the following property: - -```json -"myPage": { - "title": "Page 1", - "type": "object", - "properties": { - ... - }, - "displayModelCard": false, -} -``` - -Note: This will only hide it from the model page, the data will still persist in the version metadata. - -### Dependencies - -A dependency is useful when the answer to one question might warrant some additional information; for example, a boolean -question might not need a detailed response if the answer is 'no', but if the user answer is 'yes' you might want to ask -them for some additional details. - -To avoid validation errors, Bailo schema dependencies need to be handled slightly differently to the ones provided in -the RJSF documentation. Here is an example of how we handle dependencies for Bailo schemas: - -```json -"myPage": { - "title": "Page 1", - "type": "object", - "properties": { - "questionOne": { - "type": "boolean", - "title": "True or false?", - }, - "questionTwo": { - "title": "More information please!", - "type": "string", - } - }, - "dependencies": { - "questionOne": { - "oneOf": [ - { - "properties": { - "questionOne": { - "enum": [false], - "readOnly": false - }, - "questionTwo": { - "readOnly": true - } - }, - "required": ["questionOne"], - "additionalProperties": false - }, - { - "properties": { - "questionOne": { - "enum": [true], - "readOnly": false - }, - "questionTwo": { - "readOnly": false - } - }, - "required": ["questionOne", "questionTwo"], - "additionalProperties": false - } - ] - } - }, - "required": ["questionOne"] -} -``` - -Inside `dependencies` we have defined a case of only having one of two different situations. Firstly, if `questionOne` -is set to `false`, then `questionTwo` will be set to read only, whereas if we set `questionOne` to `true` then -`questionTwo` will not be set as read only. This method might seem slightly more convoluted than the documentation -online, but it allows for answers to be changed without making the schema invalid. The current design of RJSF's -dependencies works as so: - -- User selects `true` for `questionOne` -- User enters data into `questionTwo` -- User changes their mind and selects `false` for `questionOne` -- User data for `questionTwo` remains in the form data, despite not being visible on the form itself - -This behaviour is so that any user data is retained in case the user wishes to select `true` for `questionOne` again. -From a user perspective this nice as it means there is less chance of data being lost when changing answers, but it does -have a knock-on affect whereby in certain situations it will make the schema fail validation. Our approach is set the -additional questions to read only when they are not in use. The downside to this approach is that we potentially include -unwanted additional data, but this can be removed by the user if this happens. - -## Uploading a schema - -There are two ways of uploading a schema to Bailo. The first is by manually adding it to the `schemas` collection in -Mongo directly, or, by using the addUploadSchemas.ts / addDeploymentScript.ts scripts found within -`backend/src/scripts`. This process is not currently very graceful and requires some minor editing of the scripts -themselves. - -First, you will need to change the import at the top of the file so that it points to your new schema, and not the -minimal schema. Next, where we call `createSchema()` you will need to amend the supplied parameters of `name` and -`reference` as Mongo will not accept multiple schemas with the same name or reference. - -Once this script has been changed, run: - -```bash -npm run script -- addUploadSchema -``` - -Or for deployments: - -```bash -npm run script -- addDeploymentSchema -``` - -export default ({ children }) => {children} diff --git a/frontend/pages/docs/v1/administration/getting-started/helm-deployments.mdx b/frontend/pages/docs/v1/administration/getting-started/helm-deployments.mdx deleted file mode 100644 index 3e5a991a3c..0000000000 --- a/frontend/pages/docs/v1/administration/getting-started/helm-deployments.mdx +++ /dev/null @@ -1,63 +0,0 @@ -import DocsWrapper from 'src/docs/DocsWrapper' - -# Helm Deployments - -> At the moment `helm/bailo` is configured for OpenShift deployment, our default deployment target. Support for -> Kubernetes is on the way. We have heard that external organisations have had success already by disabling 'routes' and -> setting 'ingresses' instead. - -## Requirements - -- [HELM CLI](https://github.com/helm/helm/releases) -- [Kubectl](https://kubernetes.io/docs/tasks/tools/) - -### Optional - -OC is required for deployments to OpenShift - -- [OpenShift CLI](https://mirror.openshift.com/pub/openshift-v4/clients/oc/latest/linux/oc.tar.gz) - -## Deployment - -### Setup - -All commands assume they are run in the `helm/bailo` directory. The user should have already authenticated `kubectl` to -their cluster and changed to the correct context: - -1. `kubectl config set-context --current --namespace=bailo` - -To deploy to `OpenShift`, `oc` must also be configured correctly. - -### Configuration - -Deployment options can be overridden by including a `--values ` to a Helm command, or by -using `--set