ESA Datalabs GraphQL API Reference

This documentation lists all the GraphQL endpoints (queries, mutations, subscriptions) that are available in the ESA Datalabs system, describes their input and output parameters and shows example queries. It also describes in detail all the data types, inputs used in the inputs and outputs.

Contact

EDL Support

https://support.cosmos.esa.int/situ-service-desk/servicedesk/customer/portal/5

Terms of Service

https://datalabs.esa.int/p/terms-and-conditions

API Endpoints
# Production:
https://datalabs.esa.int/graphql
# Pre-production:
https://datalabs.datk8spre.ebe.lan/graphql

Pre-conditions for using the ESA Datalabs GraphQL API

To use the ESA Datalabs GraphQL API, the external system or query tool needs to be configured to send the requests to the URL https://datalabs.esa.int/graphql.

The user requires an ESA Cosmos CAS LDAP (https://cas.cosmos.esa.int/cas/login) account which has been granted access to the ESA Datalabs platform. For getting a user account and access to EDL platform, please submit a registration request here - https://www.cosmos.esa.int/web/datalabs/self-registration.

The user account needs to have the roles that have the permissions needed to use the specific GraphQL queries, mutations. A new regular user account that is created as a result of self-registration may not have all the necessary rights by default. For additional permissions needed for specific GraphQL API services, please contact EDL Support.

For the POST requests to be recognized and responded to, the request header needs to contain the element 'Authorization' with value 'Bearer <token, which can be found in the https://datalabs.esa.int cookie as the element 'session' value>'. To get the session token value, log into https://datalabs.esa.int with the user account and copy the session token value from the cookie in your browser local storage.

If the Query or Response example contains the a "Fragment" block with the following pattern - ...Fragment - then this block can contain attributes which are listed in the "Types" sections sub-chapter of the data type whose name is before the suffix 'Fragment'. For example ...RoleFragment attributes can be found in the Types chapter for Role etc.

There exists an interactive EDL GraphQL API browsing and query tool which is available at https://datalabs.esa.int/graphiql

Queries

authorizedObjects

Description

List of targets that the user has been authorized to use

  1. Permissions required: user-management/view on target user.
  2. UI contexts: not use in UI.
  3. Data returned: see listed field(s) of the response data type(s).
  4. Filter: only permissions a single namespace that a single user specified in the query input has access to via the roles.
  5. Input variables: userID, seppNamespace. For full list of request structure see example query.
Response

Returns [ObjectID!]!

Arguments
Name Description
userID - ID! Unique identifier of the user. Example: etestuser
seppNamespace - String! Namespace of the permissions that need to be retrieved. Example: pipeline-services

Example

Query
query AuthorizedObjects(
  $userID: ID!,
  $seppNamespace: String!
) {
  authorizedObjects(
    userID: $userID,
    seppNamespace: $seppNamespace
  ) {
    objectID
  }
}
Variables
{"userID": "etestuser", "seppNamespace": "pipeline-services"}
Response
{
  "data": {
    "authorizedObjects": [
      {"objectID": ["3d4683c4-699f-4a1a-b317-8c4b3dce23bf"]}
    ]
  }
}
Queries

bot

Description

Retrieve a single bot

  1. Permissions required: user-management/view(bot)
  2. UI contexts: not implemented in the UI
  3. Data returned: see listed field(s) of the response data type(s).
  4. Filter: none
  5. Input variables: id of the bot.
Response

Returns a Bot!

Arguments
Name Description
id - ID! Unique identifier of a bot. Example: 83bc47b09992c48d

Example

Query
query Bot($id: ID!) {
  bot(id: $id) {
    id
    name
    key
  }
}
Variables
{"id": "83bc47b09992c48d"}
Response
{
  "data": {
    "bot": {
      "id": "83bc47b09992c48d",
      "name": "testingBot",
      "key": "f2061d02bff8a5985e1864b28b74a1bc588310fb3c4d2f82ac24a272f7d7f169"
    }
  }
}
Queries

bots

Description

List all bots

  1. Permissions required: user-management/view(bot)
  2. UI contexts: not implemented in UI
  3. Data returned: id, name, key. see listed field(s) of the response data type(s).
  4. Filter: none
  5. Input variables: no variables, just the list of attributes needed in the response (id, name, key).
Response

Returns [Bot!]!

Example

Query
query Bots {
  bots {
    id
    name
    key
  }
}
Response
{
  "data": {
    "bots": [
      {
        "id": "83bc47b09992c48d",
        "name": "testingBot",
        "key": "f2061d02bff8a5985e1864b28b74a1bc588310fb3c4d2f82ac24a272f7d7f169"
      }
    ]
  }
}
Queries

checkDatalabSecret

Description

Check if secret corresponds to the specified datalab

Response

Returns a DatalabSecretCheck!

Arguments
Name Description
id - ID!
secret - String!

Example

Query
query CheckDatalabSecret(
  $id: ID!,
  $secret: String!
) {
  checkDatalabSecret(
    id: $id,
    secret: $secret
  ) {
    username
    valid
  }
}
Variables
{"id": "5fd91ad78d82ffd9", "secret": "c778916bdb923476"}
Response
{"data": {"checkDatalabSecret": {"username": "etestuser", "valid": true}}}
Queries

dataCentres

Description

Query is performed to populate and allow the selection between clusters where the user wants to launch datalabs or pipelines.

  1. Permissions required: user-management/view on target user
  2. UI contexts: 2.1. When user opens any EDL page. The result is populated into the cluster selection menu that can be opened from the top right menu bar.
  3. Data returned: see listed field(s) of the response data type(s).
  4. Filter: none
  5. Input variables: none
Response

Returns [DataCentre]!

Example

Query
query DataCentres {
  dataCentres {
    id
    displayName
    clusters {
      id
      displayName
      displayLabel
      default
      dataCentreId
    }
  }
}
Response
{
  "data": {
    "dataCentres": [
      {
        "id": "esadc01",
        "displayName": "ESA",
        "clusters": [Cluster]
      }
    ]
  }
}
Queries

dataVolumes

Description

List all data volumes of the current user

  1. Requires permission: data-volumes/view on target data-volume
  2. UI contexts: 2.1. When user opens the landing page of EDL after successfully logging in.
  3. Data returned: see listed field(s) of the reponse data type(s).
  4. Filter: only data volumes accessible to the current user are returned.
  5. Input arguments: clusterID"
Response

Returns [DataVolume!]!

Arguments
Name Description
clusterId - ID Unique identifier of the cluster in which the data volumes of the current user need to be searched

Example

Query
query DataVolumes($clusterId: ID) {
  dataVolumes(clusterId: $clusterId) {
    dvId
    name
    path
    url
    dataCentreIds
    clusterIds
    automount
  }
}
Variables
{"clusterId": "c-m-m28vdqgf"}
Response
{
  "data": {
    "dataVolumes": [
      {
        "dvId": "a96cc3db403a7567",
        "name": "JWST - Public Data",
        "path": "jwst_jwst01_data",
        "url": "nfs://server1.volumes.datalabs.esa.int/jwst_jwst01_data",
        "dataCentreIds": ["*"],
        "clusterIds": ["c-m-m28vdqgf"],
        "automount": true
      }
    ]
  }
}
Queries

datalab

Description

Retrieve a single datalab

Response

Returns a Datalab!

Arguments
Name Description
id - ID!

Example

Query
query Datalab($id: ID!) {
  datalab(id: $id) {
    id
    dlp {
      id
      name
      image
      description
      config
      version
    }
    nodeUrl
    containerId
    name
    creation_time
    secret
    categories
    state
    details
    config
    resources {
      id
      dlId
      name
      type
      categories
      specification
      state
      details
    }
    launchRef
    clusterId
    last_access_time
  }
}
Variables
{"id": "0cc7edf6-736b-42f6-891f-f395cc7896bc"}
Response
{
  "data": {
    "datalab": {
      "id": "0cc7edf6-736b-42f6-891f-f395cc7896bc",
      "dlp": DatalabPackage,
      "nodeUrl": "",
      "containerId": "",
      "name": "jl-pipeman",
      "creation_time": "2025-01-14T12:15:30.062338",
      "secret": "cb3517e95b5cbacf",
      "categories": 1,
      "state": "running",
      "details": "",
      "config": null,
      "resources": [Resource],
      "launchRef": null,
      "clusterId": "c-m-m28vdqgf",
      "last_access_time": "2025-01-14T16:18:22.071397"
    }
  }
}
Queries

datalabFromInterface

Description

Retrieve a single datalab from interface id

Response

Returns a Datalab!

Arguments
Name Description
dli_id - ID!

Example

Query
query DatalabFromInterface($dli_id: ID!) {
  datalabFromInterface(dli_id: $dli_id) {
    id
    dlp {
      id
      name
      image
      description
      config
      version
    }
    nodeUrl
    containerId
    name
    creation_time
    secret
    categories
    state
    details
    config
    resources {
      id
      dlId
      name
      type
      categories
      specification
      state
      details
    }
    launchRef
    clusterId
    last_access_time
  }
}
Variables
{"dli_id": "39925f14ea51ac71"}
Response
{
  "data": {
    "datalabFromInterface": {
      "id": "0cc7edf6-736b-42f6-891f-f395cc7896bc",
      "dlp": DatalabPackage,
      "nodeUrl": "",
      "containerId": "",
      "name": "jl-pipeman",
      "creation_time": "2025-01-14T12:15:30.062338",
      "secret": "cb3517e95b5cbacf",
      "categories": 1,
      "state": "running",
      "details": "",
      "config": null,
      "resources": [Resource],
      "launchRef": null,
      "clusterId": "c-m-m28vdqgf",
      "last_access_time": "2025-01-14T16:18:22.071397"
    }
  }
}
Queries

datalabPackages

Description

Search for the List of datalab packages from Helm repository setup in the cluster Used in DLD main screen If an id is provided it will search for the single package The clusterid is narrowing the search of package to the cluster You need to be logged in to access this query, no special roles, the package are filtered by mission so you may have some not showing up Inputs: id of the package for a single package retrieval qs is used to filter the list of packages by name, it will try to match the query string against the name of the package cluster_id is the id of the cluster Outputs: A list of Datalab packages, even for a single one, see the definition of the DatalabPackage for more details

Response

Returns [DatalabPackage!]!

Arguments
Name Description
id - ID
qs - String
categories - Int
cluster_id - ID

Example

Query
query DatalabPackages(
  $id: ID,
  $qs: String,
  $categories: Int,
  $cluster_id: ID
) {
  datalabPackages(
    id: $id,
    qs: $qs,
    categories: $categories,
    cluster_id: $cluster_id
  ) {
    id
    name
    image
    description
    config
    version
  }
}
Variables
{"id": "jl-pipeman", "qs": "", "categories": 255, "cluster_id": "c-m-m28vdqgf"}
Response
{
  "data": {
    "datalabPackages": [
      {
        "id": "jl-pipeman",
        "name": "jl-pipeman",
        "image": "jl-pipeman",
        "description": "Jupyter lab with pipeman python library.",
        "config": null,
        "version": "0.0.4"
      }
    ]
  }
}
Queries

datalabs

Description

List all instantiated datalabs.

  1. Requires permission: datalabs/view on target datalab
  2. UI contexts: 2.1. When user opens the landing page of EDL after successfully logging in.
  3. Data returned: see listed fields below.
  4. Filter: only datalabs in the authenticated user namespace are returned.
  5. Input arguments: See example query.
Response

Returns [Datalab!]!

Arguments
Name Description
clusterId - ID

Example

Query
query Datalabs($clusterId: ID) {
  datalabs(clusterId: $clusterId) {
    id
    dlp {
      id
      name
      image
      description
      config
      version
    }
    nodeUrl
    containerId
    name
    creation_time
    secret
    categories
    state
    details
    config
    resources {
      id
      dlId
      name
      type
      categories
      specification
      state
      details
    }
    launchRef
    clusterId
    last_access_time
  }
}
Variables
{"clusterId": "c-m-m28vdqgf"}
Response
{
  "data": {
    "datalabs": [
      {
        "id": "0cc7edf6-736b-42f6-891f-f395cc7896bc",
        "dlp": DatalabPackage,
        "nodeUrl": "",
        "containerId": "",
        "name": "jl-pipeman",
        "creation_time": "2025-01-14T12:15:30.062338",
        "secret": "cb3517e95b5cbacf",
        "categories": 1,
        "state": "running",
        "details": "",
        "config": null,
        "resources": [Resource],
        "launchRef": null,
        "clusterId": "c-m-m28vdqgf",
        "last_access_time": "2025-01-14T16:18:22.071397"
      }
    ]
  }
}
Queries

dockerImages

Description

List available docker images for pipeline steps

  1. Permissions required: pipeline-services/launch on target system-pipeline
  2. UI contexts: 2.1. When user opens the 'Docker image selection' modal window by clicking the 'Browse' button on 'Pipeline Editor' page 'Pipeline step' tab.
  3. Data returned: see listed field(s) of the response data type(s).
  4. Filter: list of docker images available in the currently selected cluster
  5. Input variables: none
Response

Returns [DockerImage]!

Example

Query
query DockerImages {
  dockerImages {
    name
    versions
  }
}
Response
{"data": {"dockerImages": [{"name": "step/example_base", "versions": ["v1"]}]}}
Queries

dockerRegistry

Description

Get docker registry where runner can pull images

  1. Permissions required: pipeline-services/launch on target system-pipeline
  2. UI contexts: 2.1. not used in UI.
  3. Data returned: docker registry name or URL
  4. Filter: none
  5. Input variables: none
Response

Returns a String!

Example

Query
query DockerRegistry {
  dockerRegistry
}
Response
{"data": {"dockerRegistry": "some-value"}}
Queries

executionEngines

Description

List all deployed pipeline execution backends

  1. Permissions required: pipeline-services/read on target execution-engine
  2. UI contexts: 2.1. When user opens the Pipelines dashboard page.
  3. Data returned: see listed field(s) of the response data type(s).
  4. Filter: none
  5. Input variables: none.
Response

Returns [ExecutionEngine]!

Example

Query
query ExecutionEngines {
  executionEngines {
    name
    displayName
    status
  }
}
Response
{
  "data": {
    "executionEngines": [
      {"name": "CALRISSIAN", "displayName": "Calrissian", "status": "UP"}
    ]
  }
}
Queries

extractDatalabMetadata

Description

Retrieve the metadata from the Git repository and return them to the UI It relies on a tekton pipeline to clone and read the file. Used in datalab creation flow Inputs: datalab id from which we need to extract the metadata (git repos is updated before) Outputs: a list of metadata, check MetadataEntry definition for more

Response

Returns [MetadataEntry!]!

Arguments
Name Description
datalab - ID!

Example

Query
query ExtractDatalabMetadata($datalab: ID!) {
  extractDatalabMetadata(datalab: $datalab) {
    name
    value
    definition {
      description
      type
      visibility
      owner
      required
      sensitive
      recommended
      pattern
      errorMessage
    }
  }
}
Variables
{"datalab": "cdce7d27-fc5e-44da-b326-875624b6cbac"}
Response
{
  "data": {
    "extractDatalabMetadata": [
      {
        "name": "version",
        "value": "1.0.0",
        "definition": MetadataEntryDefinition
      }
    ]
  }
}
Queries

getAuthenticationState

Description

Return the available backends and the current user, if one has authenticated. Representation of how the server currently recognized the client, and possible methods for authentication

  1. Access roles: none required
  2. UI contexts: When user opens the EDL login page or any other page or refreshes a page after being authenticated.
  3. Data returned: see listed field(s) of the reponse data type(s).
  4. Filter: none
  5. Input arguments: none
Response

Returns an AuthenticationState!

Example

Query
query GetAuthenticationState {
  getAuthenticationState {
    backends
    username
    token
    timestamp
    user {
      username
      displayName
      roles {
        ...RoleFragment
      }
    }
  }
}
Response
{
  "data": {
    "getAuthenticationState": {
      "backends": "CAS",
      "username": "etestuser",
      "token": "eyJ1c2VyX2lkIjogInVzZXIifQ.ZkYBTw.GRLKzLezKcpdH7MJueKnUIdBl8M",
      "timestamp": 1715616642,
      "user": User
    }
  }
}
Queries

getBookmarks

Description

Retrieve the list of datalab the user has bookmarked Used in main screen You need to be logged in to perform this operation Outputs: a list of bookmark, check BuildBookmarks definition for more

Response

Returns [BuildBookmarks!]!

Example

Query
query GetBookmarks {
  getBookmarks {
    datalab
  }
}
Response
{
  "data": {
    "getBookmarks": [{"datalab": "cdce7d27-fc5e-44da-b326-875624b6cbac"}]
  }
}
Queries

getBuilds

Description

Retrieve all the builds regardless of the datalab Used in main screen and sharing screen of the datalab detailed view If an id is provided it will return only this build You need to be logged in to perform this operation, the build are filtered based on you role Inputs: the build id (optional) qs is used to filter based on the datalab name and description Outputs: a list of build, check DatalabBuild definition for more

Response

Returns [DatalabBuild!]!

Arguments
Name Description
id - ID
qs - String

Example

Query
query GetBuilds(
  $id: ID,
  $qs: String
) {
  getBuilds(
    id: $id,
    qs: $qs
  ) {
    id
    datalabId
    version
    status
    runtimeConfiguration {
      cpuAllocation
      memAllocation
    }
    created_at
    buildRef
    scanRef
    logs
    progress
  }
}
Variables
{"id": "3d971341-136b-43e6-8298-bd8913edf77b", "qs": ""}
Response
{
  "data": {
    "getBuilds": [
      {
        "id": "3d971341-136b-43e6-8298-bd8913edf77b",
        "datalabId": "b27cda74-2db7-46ec-b287-a6353a47e74a",
        "version": "0.0.1-0",
        "status": "PUBLISHED",
        "runtimeConfiguration": RuntimeConfiguration,
        "created_at": "1715696521.537044",
        "buildRef": "sciapps-build-datalab-4ltcw",
        "scanRef": null,
        "logs": "Build started (sciapps-build-datalab-4ltcw)#!1715696521.539653!#Build ended with status BUILD_SUCCESS#!1715696617.206669!#Build marked as UNDER_MODERATION#!1715697174.958686!#Build marked as PUBLISHED#!1715697826.405907!#Approved#!1715697826.407465!#Datalab build published in the public catalog#!1715697848.135899!#Build archived#!1715773558.998771!#Build unarchived#!1715783367.895708!#Datalab build published in the public catalog#!1715783388.069154!#",
        "progress": "BUILD_SUCCESS"
      }
    ]
  }
}
Queries

getDatalab

Description

Returns a single datalab by ID Used in DLD main screen You need to be logged and being the owner of the datalab (Operator can see them) Inputs: datalab_id is the id of the datalab in the dalabclass terms Outputs: a single of datalab class

Response

Returns a DatalabClass

Arguments
Name Description
datalab_id - ID!

Example

Query
query GetDatalab($datalab_id: ID!) {
  getDatalab(datalab_id: $datalab_id) {
    id
    owner {
      username
      displayName
      roles {
        ...RoleFragment
      }
    }
    is_public
    created_at
    modified_at
    repository
    branch
    artefact
    status
    name
    description
    icon
    runtimeConfiguration {
      cpuAllocation
      memAllocation
    }
    metadata {
      name
      value
      definition {
        ...MetadataEntryDefinitionFragment
      }
    }
    nstars
    version
  }
}
Variables
{"datalab_id": "0cc7edf6-736b-42f6-891f-f395cc7896bc"}
Response
{
  "data": {
    "getDatalab": {
      "id": "deaef60e-bde6-4ca8-b284-79b03db417b2",
      "owner": User,
      "is_public": false,
      "created_at": "1715163378.021328",
      "modified_at": "1715163471.601883",
      "repository": null,
      "branch": null,
      "artefact": null,
      "status": "DRAFT",
      "name": "testing-lab",
      "description": "A test",
      "icon": null,
      "runtimeConfiguration": RuntimeConfiguration,
      "metadata": [MetadataEntry],
      "nstars": 0,
      "version": "0.0.1"
    }
  }
}
Queries

getDatalabAccessList

Description

Returns the list of users that has rights to access this datalab even if not public yet The list of users with whom the datalab was shared Used in share screen of datalab details view You need to be developer to perform this operation Inputs: datalab_id the datalab for which we need the list of users having access Outputs: a list of user, check User definition (in directory.graphql) for more information

Response

Returns [User!]!

Arguments
Name Description
datalab_id - ID!

Example

Query
query GetDatalabAccessList($datalab_id: ID!) {
  getDatalabAccessList(datalab_id: $datalab_id) {
    username
    displayName
    roles {
      id
      description
      target
      permissions {
        ...PermissionFragment
      }
      cosmosLdapGroup
    }
  }
}
Variables
{"datalab_id": "0cc7edf6-736b-42f6-891f-f395cc7896bc"}
Response
{
  "data": {
    "getDatalabAccessList": [
      {
        "username": "etestuser",
        "displayName": "EDL Test User",
        "roles": [Role]
      }
    ]
  }
}
Queries

getDatalabBuilds

Description

Retrieve the list of build for a given datalab Used in main screen and testing screen of the datalab detailed view You need to be logged in to perform this operation, the build are also needed for the runtime in order to select the version to start. Inputs: datalab_id the datalab for which we need the builds Outputs: a list of build, check DatalabBuild definition for more information

Response

Returns [DatalabBuild!]!

Arguments
Name Description
datalab_id - ID!

Example

Query
query GetDatalabBuilds($datalab_id: ID!) {
  getDatalabBuilds(datalab_id: $datalab_id) {
    id
    datalabId
    version
    status
    runtimeConfiguration {
      cpuAllocation
      memAllocation
    }
    created_at
    buildRef
    scanRef
    logs
    progress
  }
}
Variables
{"datalab_id": "0cc7edf6-736b-42f6-891f-f395cc7896bc"}
Response
{
  "data": {
    "getDatalabBuilds": [
      {
        "id": "3d971341-136b-43e6-8298-bd8913edf77b",
        "datalabId": "b27cda74-2db7-46ec-b287-a6353a47e74a",
        "version": "0.0.1-0",
        "status": "PUBLISHED",
        "runtimeConfiguration": RuntimeConfiguration,
        "created_at": "1715696521.537044",
        "buildRef": "sciapps-build-datalab-4ltcw",
        "scanRef": null,
        "logs": "Build started (sciapps-build-datalab-4ltcw)#!1715696521.539653!#Build ended with status BUILD_SUCCESS#!1715696617.206669!#Build marked as UNDER_MODERATION#!1715697174.958686!#Build marked as PUBLISHED#!1715697826.405907!#Approved#!1715697826.407465!#Datalab build published in the public catalog#!1715697848.135899!#Build archived#!1715773558.998771!#Build unarchived#!1715783367.895708!#Datalab build published in the public catalog#!1715783388.069154!#",
        "progress": "BUILD_SUCCESS"
      }
    ]
  }
}
Queries

getDatalabComments

Description

Retrieve the comment for a databab Used in main screen You need to be logged in and the datalab to be public Inputs: a datalab id Outputs: a list of comment, check UserComment definition

Response

Returns [UserComment!]!

Arguments
Name Description
datalab - ID!

Example

Query
query GetDatalabComments($datalab: ID!) {
  getDatalabComments(datalab: $datalab) {
    datalab_id
    build_version
    modified_at
    comment
    user {
      username
      displayName
      roles {
        ...RoleFragment
      }
    }
  }
}
Variables
{"datalab": "cdce7d27-fc5e-44da-b326-875624b6cbac"}
Response
{
  "data": {
    "getDatalabComments": [
      {
        "datalab_id": "0cc7edf6-736b-42f6-891f-f395cc7896bc",
        "build_version": "1.0.2",
        "modified_at": "1715697428.874147",
        "comment": "Great!",
        "user": User
      }
    ]
  }
}
Queries

getDatalabs

Description

List the available datalabs in DLD terms, this list is relying on datalabs the user owns or that are publicly available, shared with him. Moderator will also get the list of undermoderation datalab It contains a list of datalab that could be under development. Used in DLD main screen You need to be logged in to see the list of datalabs Inputs: qs is a string to that must match the name/description of the datalab, used to perform search cluster_id is a string to target a specific cluster Outputs: a list of datala, see the DatalabClass definition for more information

Response

Returns [DatalabClass!]!

Arguments
Name Description
qs - String
cluster_id - ID

Example

Query
query GetDatalabs(
  $qs: String,
  $cluster_id: ID
) {
  getDatalabs(
    qs: $qs,
    cluster_id: $cluster_id
  ) {
    id
    owner {
      username
      displayName
      roles {
        ...RoleFragment
      }
    }
    is_public
    created_at
    modified_at
    repository
    branch
    artefact
    status
    name
    description
    icon
    runtimeConfiguration {
      cpuAllocation
      memAllocation
    }
    metadata {
      name
      value
      definition {
        ...MetadataEntryDefinitionFragment
      }
    }
    nstars
    version
  }
}
Variables
{"qs": "", "cluster_id": "c-m-m28vdqgf"}
Response
{
  "data": {
    "getDatalabs": [
      {
        "id": "deaef60e-bde6-4ca8-b284-79b03db417b2",
        "owner": User,
        "is_public": false,
        "created_at": "1715163378.021328",
        "modified_at": "1715163471.601883",
        "repository": null,
        "branch": null,
        "artefact": null,
        "status": "DRAFT",
        "name": "testing-lab",
        "description": "A test",
        "icon": null,
        "runtimeConfiguration": RuntimeConfiguration,
        "metadata": [MetadataEntry],
        "nstars": 0,
        "version": "0.0.1"
      }
    ]
  }
}
Queries

getDeploymentError

Description

Returns the error that occurred when deploying a datalab instance You need to be logged in Inputs: instance id Outputs: dictionary with error indication and comment

Response

Returns a DeploymentError!

Arguments
Name Description
instance - ID!

Example

Query
query GetDeploymentError($instance: ID!) {
  getDeploymentError(instance: $instance) {
    hasError
    message
    inProgress
  }
}
Variables
{"instance": "0cc7edf6-736b-42f6-891f-f395cc7896bc"}
Response
{
  "data": {
    "getDeploymentError": {
      "hasError": true,
      "message": "pods \"datalab-ff02932e67a79164-598bc9b866-fpsg4\" is forbidden: exceeded quota: user-quota, requested: limits.cpu=88, used: limits.cpu=0, limited: limits.cpu=16:replicas: 0/1",
      "inProgress": true
    }
  }
}
Queries

getLicenses

Description

Returns the list of licence Used in datalab details view in the share screen You need to be a developer Inputs: Nothing Outputs: a list of License, see License for more information

Response

Returns [License!]!

Example

Query
query GetLicenses {
  getLicenses {
    name
    id
    link
    category
  }
}
Response
{
  "data": {
    "getLicenses": [
      {
        "name": "Apache License 2.0",
        "id": "Apache-2.0",
        "link": "https://www.apache.org/licenses/LICENSE-2.0",
        "category": "Popular Licenses"
      }
    ]
  }
}
Queries

getLogLevel

Description

Current log level of modules

Response

Returns a LogLevel!

Arguments
Name Description
module - String! Full module path

Example

Query
query GetLogLevel($module: String!) {
  getLogLevel(module: $module)
}
Variables
{"module": "some-value"}
Response
{"data": {"getLogLevel": "NOTSET"}}
Queries

getOperatorDefinedRoles

Description

List all operator defined roles

  1. Permissions required: user-management/view on target role
  2. UI contexts: not used in the user interface.
  3. Data returned: see listed field(s) of the response data type(s).
  4. Filter: only roles where the namespace equals "operator-defined" are returned.
  5. Input variables: For full list of request structure see example query.
Response

Returns [Role]!

Example

Query
query GetOperatorDefinedRoles {
  getOperatorDefinedRoles {
    id
    description
    target
    permissions {
      id
      description
      target
    }
    cosmosLdapGroup
  }
}
Response
{
  "data": {
    "getOperatorDefinedRoles": [
      {
        "id": "resource-management/datalab",
        "description": "Datalab role on the jl-pipeman target with the namespace resource-management",
        "target": "jl-pipeman",
        "permissions": [Permission],
        "cosmosLdapGroup": "XYZ Datalabs Member"
      }
    ]
  }
}
Queries

getPermissions

Description

List all permissions.

  1. Permissions required: "user-management/view" on target "permission"
  2. UI contexts: 2.1. When user opens the Permissions page by clicking the Add button in the Permissions block of the Access Control page.
  3. Data returned: see listed field(s) of the response data type(s).
  4. Filter: none
  5. Input variables: No variables, requested attributes are id,description,target.
Response

Returns [Permission!]!

Example

Query
query GetPermissions {
  getPermissions {
    id
    description
    target
  }
}
Response
{
  "data": {
    "getPermissions": [
      {
        "id": "workspace-services/manage",
        "description": "Testing the permission creation for ICD documentation",
        "target": "dez6"
      }
    ]
  }
}
Queries

getQuota

Description

Returns the current usage and availability of the CPU and Memory on the user namespace Used in main screen in the launch popup and inside the testing screen You need to be logged in Inputs: nothing Outputs: a quota for the CPU and memory, see the Quota for more information

Response

Returns a Quota!

Arguments
Name Description
cluster_id - ID

Example

Query
query GetQuota($cluster_id: ID) {
  getQuota(cluster_id: $cluster_id) {
    cpuLimit
    memoryLimit
    usedCpu
    usedMemory
    usedApp
    appLimit
    usedGroups
    groupsLimit
  }
}
Variables
{"cluster_id": "c-m-m28vdqgf"}
Response
{
  "data": {
    "getQuota": {
      "cpuLimit": "16",
      "memoryLimit": "64Gi",
      "usedCpu": "250m",
      "usedMemory": "384Mi",
      "usedApp": "2",
      "appLimit": "3",
      "usedGroups": 3,
      "groupsLimit": 16
    }
  }
}
Queries

getRole

Description

Retrieve a single role permissions.

  1. Permissions required: "user-management/view" on target "role"
  2. UI contexts: 2.1. When user clicks on the row of a role in the Roles block on the "Access Control" page. 2.2. When user has successfully added a permission to the role. 2.3. When user has successfully removed a permission from the role.
  3. Data returned: In UI context of 2.1. id,description,target. See listed field(s) of the response data type(s).
  4. Filter: none
  5. Input variables: In the UI context of 2.1. the variable roleID is submitted with the query. Example variable: "rid": "datalabs/tst". For full list of request structure see example query.
Response

Returns a Role!

Arguments
Name Description
roleID - ID! Unique identifier of the role on EDL roles table. Example variable value: datalabs/tst.

Example

Query
query GetRole($roleID: ID!) {
  getRole(roleID: $roleID) {
    id
    description
    target
    permissions {
      id
      description
      target
    }
    cosmosLdapGroup
  }
}
Variables
{"roleID": "workspace-services/team-member/TestLuisan"}
Response
{
  "data": {
    "getRole": {
      "id": "resource-management/datalab",
      "description": "Datalab role on the jl-pipeman target with the namespace resource-management",
      "target": "jl-pipeman",
      "permissions": [Permission],
      "cosmosLdapGroup": "XYZ Datalabs Member"
    }
  }
}
Queries

getRoles

Description

List all roles available in the EDL system.

  1. Permissions required: "user-management/view" on target "role"
  2. UI contexts: 2.1. When user opens the "Access Control" page from the "Operator" menu. 2.2. When user clicks the "Add roles" button on the "User management" page.
  3. Data returned: All roles within the system. See listed field(s) of the response data type(s).
  4. Filter: none.
  5. Input variables: For context 2.1. the request structure includes id,description,target. For full list of request structure see example query.
Response

Returns [Role!]!

Example

Query
query GetRoles {
  getRoles {
    id
    description
    target
    permissions {
      id
      description
      target
    }
    cosmosLdapGroup
  }
}
Response
{
  "data": {
    "getRoles": [
      {
        "id": "resource-management/datalab",
        "description": "Datalab role on the jl-pipeman target with the namespace resource-management",
        "target": "jl-pipeman",
        "permissions": [Permission],
        "cosmosLdapGroup": "XYZ Datalabs Member"
      }
    ]
  }
}
Queries

getRolesFromPermission

Description

Retrieve a list of roles that contain a certain permission.

  1. Permissions required: user-management/view on target role
  2. UI contexts: not used in UI
  3. Data returned: see listed field(s) of the response data type(s).
  4. Filter: only roles that contain a certain permission are retrieved.
  5. Input variables: permID.
Response

Returns [Role!]!

Arguments
Name Description
permID - ID! Permission unique identifier is composed of namespace/identifier/target. Example: pipeline-services/launch/test-pipeline

Example

Query
query GetRolesFromPermission($permID: ID!) {
  getRolesFromPermission(permID: $permID) {
    id
    description
    target
    permissions {
      id
      description
      target
    }
    cosmosLdapGroup
  }
}
Variables
{"permID": "data-volumes/gd/f"}
Response
{
  "data": {
    "getRolesFromPermission": [
      {
        "id": "resource-management/datalab",
        "description": "Datalab role on the jl-pipeman target with the namespace resource-management",
        "target": "jl-pipeman",
        "permissions": [Permission],
        "cosmosLdapGroup": "XYZ Datalabs Member"
      }
    ]
  }
}
Queries

getUser

Description

Retrieve a single user roles and permissions.

  1. Permissions required: "user-management/view" on target "user"
  2. UI contexts: 2.1. When user clicks on a single user row on the "User management" (user-manager) page of EDL. 2.2. When user clicks on the button "Select roles" in the modal windows "Roles".
  3. Data returned: see example response for details.
  4. Filter: only the data of the user specified in the input variables.
  5. Input variables: UserID. See example query.
Response

Returns a User!

Arguments
Name Description
userID - ID! Unique identifier of the user in EDL users table. Example value: etestuser

Example

Query
query GetUser($userID: ID!) {
  getUser(userID: $userID) {
    username
    displayName
    roles {
      id
      description
      target
      permissions {
        ...PermissionFragment
      }
      cosmosLdapGroup
    }
  }
}
Variables
{"userID": "etestuser"}
Response
{
  "data": {
    "getUser": {
      "username": "etestuser",
      "displayName": "EDL Test User",
      "roles": [Role]
    }
  }
}
Queries

getUsers

Description

List all SEPP directory users.

  1. Permissions required: "user-management/view" on target "user"
  2. UI contexts: 2.1. When user opens the user-manager page via Operator menu option "Users". 2.2. When Team member selection list is displayed as a result of clicking "Add manager" or "Add regular member" button on the "Team Members" page.
  3. Data returned: username, displayName. See example response.
  4. Filter: none, all users in the system database are listed.
  5. Input variables: for 2.1. context only username,displayName are included in the query request.
Response

Returns [User!]!

Example

Query
query GetUsers {
  getUsers {
    username
    displayName
    roles {
      id
      description
      target
      permissions {
        ...PermissionFragment
      }
      cosmosLdapGroup
    }
  }
}
Response
{
  "data": {
    "getUsers": [
      {
        "username": "etestuser",
        "displayName": "EDL Test User",
        "roles": [Role]
      }
    ]
  }
}
Queries

getWorkspace

Description

Retrieve a single workspace data.

  1. Permissions required: workspace-services/view on target workspaceName
  2. UI contexts: 2.1. Used in asynchronous refresh processes on the user interface of the page Team Members 2.2. When team members are added or removed on page "Team Members" 2.3. When a new workspace has been created and its data is first displayed on page "Team Members" 2.4. When workspace data has been updated and the updated data is displayed on page "Team Members"
  3. Data returned: see listed field(s) of the response data type(s).
  4. Filter: Data of a single workspace is returned
  5. Input variables: Team workspace 'Short name'.
Response

Returns a Workspace!

Arguments
Name Description
workspaceName - ID! Unique 'Short name' of the team (workspace)

Example

Query
query GetWorkspace($workspaceName: ID!) {
  getWorkspace(workspaceName: $workspaceName) {
    workspaceID
    workspaceName
    metadata
    members {
      username
      displayName
      roles {
        ...RoleFragment
      }
    }
  }
}
Variables
{"workspaceName": "AWorkspaceTest2"}
Response
{
  "data": {
    "getWorkspace": {
      "workspaceID": "55000",
      "workspaceName": "AWorkspaceTest2",
      "metadata": "{\"title\":\"AWorkspaceTest2 title 1\",\"alternateName\":\"AWorkspaceTest2\",\"type\":\"https://data.esa.int/esado/Team\",\"description\":\"AWorkspaceTest2 description 1 AWorkspaceTest2 description 1 AWorkspaceTest2 description 1 AWorkspaceTest2 description 1 AWorkspaceTest2 description 1 AWorkspaceTest2 description 1\"}",
      "members": [User]
    }
  }
}
Queries

getWorkspaces

Description

List all workspaces.

  1. Permissions required: workspace-services/view on target workspace
  2. UI contexts: 2.1. Not used in the user interface.
  3. Data returned: see listed field(s) of the response data type(s).
  4. Filter: none
  5. Input variables: none.
Response

Returns [Workspace!]!

Example

Query
query GetWorkspaces {
  getWorkspaces {
    workspaceID
    workspaceName
    metadata
    members {
      username
      displayName
      roles {
        ...RoleFragment
      }
    }
  }
}
Response
{
  "data": {
    "getWorkspaces": [
      {
        "workspaceID": "55000",
        "workspaceName": "AWorkspaceTest2",
        "metadata": "{\"title\":\"AWorkspaceTest2 title 1\",\"alternateName\":\"AWorkspaceTest2\",\"type\":\"https://data.esa.int/esado/Team\",\"description\":\"AWorkspaceTest2 description 1 AWorkspaceTest2 description 1 AWorkspaceTest2 description 1 AWorkspaceTest2 description 1 AWorkspaceTest2 description 1 AWorkspaceTest2 description 1\"}",
        "members": [User]
      }
    ]
  }
}
Queries

isWorkspaceNameAvailable

Description

Check if it is possible to create a workspace with that name (needs to be unique accross clusters).

  1. Permissions required: workspace-services/create on target workspace
  2. UI contexts: 2.1. On the modal window of Team workspace Settings if a name has been entered into "Workspace identifier" field.
  3. Data returned: True - name is available. False - name is not available, is already taken by another workspace.
  4. Filter: workspace with the name in the input variable is being filtered from the names of the existing workspaces of all clusters.
  5. Input variables: name for the new workspace to be created.
Response

Returns a Boolean!

Arguments
Name Description
name - String! The desired name of the new workspace which needs to be unique across all clusters.

Example

Query
query IsWorkspaceNameAvailable($name: String!) {
  isWorkspaceNameAvailable(name: $name)
}
Variables
{"name": "some-workspace-name"}
Response
{"data": {"isWorkspaceNameAvailable": true}}
Queries

loggers

Description

Registered logger modules

Response

Returns [String!]!

Example

Query
query Loggers {
  loggers
}
Response
{"data": {"loggers": ["some-value"]}}
Queries

logs

Description

Retrieve the logs of a running datalab

Response

Returns a DatalabLog

Arguments
Name Description
id - ID!
clusterId - ID

Example

Query
query Logs(
  $id: ID!,
  $clusterId: ID
) {
  logs(
    id: $id,
    clusterId: $clusterId
  ) {
    logs
    params {
      pod
      pipeline
      namespace
      cluster_id
    }
  }
}
Variables
{"id": "d94cafae-e907-47fd-9d41-23ef1798948c", "clusterId": "local"}
Response
{
  "data": {
    "logs": {
      "logs": "Running docker lint...",
      "params": LogParams
    }
  }
}
Queries

pipelineLogs

Description

Returns the logs of an entire pipeline that ran previously Used in datalab detail screen in the testing section/tab You need to be logged in Inputs: select an old pipeline that ran Outputs: the logs as a list of log object

Response

Returns a BuildLog

Arguments
Name Description
id - ID!
clusterId - ID

Example

Query
query PipelineLogs(
  $id: ID!,
  $clusterId: ID
) {
  pipelineLogs(
    id: $id,
    clusterId: $clusterId
  ) {
    logs {
      id
      log
      status
      task
      tasks
      pod
    }
    params {
      pod
      pipeline
      namespace
      cluster_id
    }
  }
}
Variables
{"id": "sciapps-build-datalab-4rnpm", "clusterId": "local"}
Response
{
  "data": {
    "pipelineLogs": {
      "logs": [DLDPipelineLog],
      "params": LogParams
    }
  }
}
Queries

pipelineRunDetails

Description

List single pipeline run details

  1. Permissions required: pipeline-services/read on target system-pipeline
  2. UI contexts: 2.1. When user opens the Pipeline run details modal window by clicking on a run card on the Pipelines Dashboard page.
  3. Data returned: see listed field(s) of the response data type(s).
  4. Filter: data of one selected pipeline run of the current user
  5. Input variables: pipeline run unique identifier
Response

Returns a PipelineRun!

Arguments
Name Description
id - ID! Unique identifier of the pipeline run about which to show the details

Example

Query
query PipelineRunDetails($id: ID!) {
  pipelineRunDetails(id: $id) {
    id
    owner {
      username
      displayName
      roles {
        ...RoleFragment
      }
    }
    pipeline {
      ... on UserPipeline {
        ...UserPipelineFragment
      }
      ... on SystemPipeline {
        ...SystemPipelineFragment
      }
    }
    identifier
    status
    totalStepCount
    steps {
      name
      startDate
      endDate
      logs {
        ...StepLogFragment
      }
      status
    }
    startDate
    endDate
    input {
      parameters {
        ...ParameterFragment
      }
    }
    output {
      outputPath
    }
    schedule {
      owner {
        ...UserFragment
      }
      cronExpression
      interval
    }
    notifications {
      email
      trigger
      triggerData {
        ...TriggerDataFragment
      }
    }
    defaultImage
    executionEngine {
      name
      displayName
      status
    }
    labels
    log {
      logs {
        ...LogFragment
      }
    }
    externalTrigger
    pipelineType
  }
}
Variables
{"id": "d94cafae-e907-47fd-9d41-23ef1798948c"}
Response
{
  "data": {
    "pipelineRunDetails": {
      "id": "d94cafae-e907-47fd-9d41-23ef1798948c",
      "owner": User,
      "pipeline": UserPipeline,
      "identifier": "pipeline-run-test-2",
      "status": "COMPLETED",
      "totalStepCount": 0,
      "steps": [StepRun],
      "startDate": "2023-06-12T08:28:49.146531",
      "endDate": "2023-06-12T08:29:40.494027",
      "input": Input,
      "output": Output,
      "schedule": Schedule,
      "notifications": [Notification],
      "defaultImage": "",
      "executionEngine": ExecutionEngine,
      "labels": ["example-run"],
      "log": PipelineLog,
      "externalTrigger": true,
      "pipelineType": "USER"
    }
  }
}
Queries

pipelineRuns

Description

List all pipeline runs

  1. Permissions required: pipeline-services/read on target system-pipeline
  2. UI contexts: 2.1. When user opens the Pipelines dashboard page. 2.2. When user changes the filtering or sorting conditions on the Pipelines dashboard page
  3. Data returned: see listed field(s) of the response data type(s).
  4. Filter: cluster, current user, offset, limit and filter string from the search box
  5. Input variables: For full list of request structure see example query.
Response

Returns a PipelineRunResult!

Arguments
Name Description
filter - String Search string that is used for filtering pipeline runs by name
offset - Int The number of search results after which to start returning the results. For example if the first page showed 50 and the user open the second page of search results then offset = 50
limit - Int The search results items limit which are returned in the response
order - RunOrder The sorting order of the the search results
clusterId - ID The identifier from the cluster where from to search for the pipeline runs

Example

Query
query PipelineRuns(
  $filter: String,
  $offset: Int,
  $limit: Int,
  $order: RunOrder,
  $clusterId: ID
) {
  pipelineRuns(
    filter: $filter,
    offset: $offset,
    limit: $limit,
    order: $order,
    clusterId: $clusterId
  ) {
    edges {
      id
      owner {
        ...UserFragment
      }
      pipeline {
        ... on UserPipeline {
          ...UserPipelineFragment
        }
        ... on SystemPipeline {
          ...SystemPipelineFragment
        }
      }
      identifier
      status
      totalStepCount
      steps {
        ...StepRunFragment
      }
      startDate
      endDate
      input {
        ...InputFragment
      }
      output {
        ...OutputFragment
      }
      schedule {
        ...ScheduleFragment
      }
      notifications {
        ...NotificationFragment
      }
      defaultImage
      executionEngine {
        ...ExecutionEngineFragment
      }
      labels
      log {
        ...PipelineLogFragment
      }
      externalTrigger
      pipelineType
    }
    pageInfo {
      totalCount
      pageCount
    }
  }
}
Variables
{
  "filter": "",
  "offset": 0,
  "limit": 50,
  "order": "STARTED_DESC",
  "clusterId": "c-m-m28vdqgf"
}
Response
{
  "data": {
    "pipelineRuns": {
      "edges": [PipelineRun],
      "pageInfo": Pagination
    }
  }
}
Queries

readAnnouncement

Description

Check if active announcement exists.

  1. Access roles: none required
  2. UI contexts: 2.1. When user opens any edl page.
  3. Data returned: see listed fields below.
  4. Filter: none
  5. Input arguments: none
Response

Returns an Announcement

Example

Query
query ReadAnnouncement {
  readAnnouncement {
    announcement
    textColorCode
    backgroundColorCode
    createdTime
  }
}
Response
{
  "data": {
    "readAnnouncement": {
      "announcement": "<br><center>Banner text update test 1</center></br>",
      "textColorCode": "#00008B",
      "backgroundColorCode": "#50EBEC",
      "createdTime": "2024-04-24T13:57:35.621599"
    }
  }
}
Queries

readHelpSectionIds

Description

Get help page ids, helps to provide more accurate anchors when needed e.g src-296321073_PipelineEditorGUI-Command

  1. Permissions required: none required
  2. UI contexts: 2.1. Pipeline Editor > Pipeline Step > the i icon next to the Scripts section.
  3. Data returned: see listed field(s) of the response data type(s).
  4. Filter: none
  5. Input variables: pathSegment, idSuffixes, reCache.
Response

Returns a HelpPageIds

Arguments
Name Description
pathSegment - String! The concrete page of the help pages which contains the needed section
idSuffixes - [String] Needed for filtering the help page section id-s which are then used to scroll the help page to the right section.
reCache - Boolean true = a new query is performed and the resulting help page html is being cached, false = help page HTML is taken from cache (if it is available there). default = False

Example

Query
query ReadHelpSectionIds(
  $pathSegment: String!,
  $idSuffixes: [String],
  $reCache: Boolean
) {
  readHelpSectionIds(
    pathSegment: $pathSegment,
    idSuffixes: $idSuffixes,
    reCache: $reCache
  ) {
    sectionIds
  }
}
Variables
{
  "pathSegment": "/Pipeline_Editor_GUI.html",
  "idSuffixes": ["PipelineEditorGUI-CommandCommand"],
  "reCache": true
}
Response
{
  "data": {
    "readHelpSectionIds": {
      "sectionIds": ["src-296321073_PipelineEditorGUI-CommandCommand"]
    }
  }
}
Queries

searchAssets

Description

Search for assets in all indices

  1. Permissions: none required
  2. UI contexts: 2.1. User clicks the Teams menu option in the User menu. 2.1. User clicks the "Add from Catalog" button in the Data Volumes page.
  3. Data returned: see thr response data example).
  4. Filter: none
  5. Input variables.
Response

Returns a String!

Arguments
Name Description
qs - String! Query string for text search.
dataCentreId - ID Optional data center unique identifier e.g to filter workspace_names

Example

Query
query SearchAssets(
  $qs: String!,
  $dataCentreId: ID
) {
  searchAssets(
    qs: $qs,
    dataCentreId: $dataCentreId
  )
}
Variables
{
  "qs": "{\"facets\":{\"asset-type\":{\"types\":[\"dataset\"]},\"lexicon\":{\"domain\":[],\"instrument\":[],\"theme\":[],\"mission\":[],\"platform\":[]},\"properties\":[\"dataVolumeURL\"]},\"query\":{\"text\":\"\"},\"display\":{\"page\":0,\"perPage\":60,\"order\":\"RELEVANCE\",\"direction\":\"ASC\"}}",
  "dataCentreId": "esadc01"
}
Response
{"data": {"searchAssets": "some-value"}}
Queries

searchUser

Description

Search for users inside LDAP server, user needs to have a cosmos account Used in datalab details view in the share screen You need to be a developer Inputs: name is the first letter of the user name Outputs: a list of LDAP user, see User (in directory.graphql) for more information

Response

Returns [User!]!

Arguments
Name Description
name - String

Example

Query
query SearchUser($name: String) {
  searchUser(name: $name) {
    username
    displayName
    roles {
      id
      description
      target
      permissions {
        ...PermissionFragment
      }
      cosmosLdapGroup
    }
  }
}
Variables
{"name": "etestuser"}
Response
{
  "data": {
    "searchUser": [
      {
        "username": "etestuser",
        "displayName": "EDL Test User",
        "roles": [Role]
      }
    ]
  }
}
Queries

startupState

Description

Query the server side readiness of the datalab

All database rows must be created, and all resources marked as REQUIRED must be in state READY. Wait up to timeout seconds before failing.

Response

Returns a Boolean

Arguments
Name Description
timeout - Int

Example

Query
query StartupState($timeout: Int) {
  startupState(timeout: $timeout)
}
Variables
{"timeout": 10}
Response
{"data": {"startupState": true}}
Queries

systemPipeline

Description

List single system pipeline details

  1. Permissions required: pipeline-services/read on target system-pipeline
  2. UI contexts: 2.1. When user opens the System Pipeline details modal window by clicking the details button on a listed item in Pipeline Editor tab Catalogue.
  3. Data returned: see listed field(s) of the response data type(s).
  4. Filter: metadata of one system pipelines available for the current user in the currently selected cluster
  5. Input variables: For full list of request structure see example query.
Response

Returns a SystemPipeline!

Arguments
Name Description
id - ID! Unique identifier of the system pipeline the details of which are queried

Example

Query
query SystemPipeline($id: ID!) {
  systemPipeline(id: $id) {
    id
    name
    description
    version {
      latestVersion
      defaultVersion
      codeVersion {
        ...SystemPipelineCodeFragment
      }
    }
    owner {
      username
      displayName
      roles {
        ...RoleFragment
      }
    }
    labels
    createdDate
    lastModified
    clusterIds
    defaultExecutionEngine {
      name
      displayName
      status
    }
    allowedRoles
  }
}
Variables
{"id": "47acb0fd-f8ee-446f-b345-4589d404c8ad"}
Response
{
  "data": {
    "systemPipeline": {
      "id": "94ce5c60-7c45-44d0-aa9e-430df28c87fe",
      "name": "BC_MCAM",
      "description": "This pipeline contains 2 steps: tm2raw_mcam and pds4_packager.",
      "version": SystemPipelineVersion,
      "owner": User,
      "labels": ["example-pipeline"],
      "createdDate": "2023-05-10T15:13:36.102336",
      "lastModified": "2023-05-10 15:14:23.097174",
      "clusterIds": ["c-m-m28vdqgf"],
      "defaultExecutionEngine": ExecutionEngine,
      "allowedRoles": ["pipeline-services/developer"]
    }
  }
}
Queries

systemPipelineCodeVersions

Description

List single system pipeline code versions

  1. Permissions required: pipeline-services/read on target system-pipeline
  2. UI contexts: 2.1. When user opens the Select Version modal window by clicking the "Change version" button on "Pull from the Catalogue" modal window.
  3. Data returned: see listed field(s) of the response data type(s).
  4. Filter: list of pipeline versions available for the current user in the currently selected cluster
  5. Input variables: unique identifier of the system pipeline
Response

Returns [SystemPipelineCode]!

Arguments
Name Description
id - ID! Unique identifier of the system pipeline

Example

Query
query SystemPipelineCodeVersions($id: ID!) {
  systemPipelineCodeVersions(id: $id) {
    owner {
      username
      displayName
      roles {
        ...RoleFragment
      }
    }
    version
    description
    createdDate
    code {
      filename
      text
    }
    entrypointFilename
  }
}
Variables
{"id": "db70a3e1-c605-44e0-8867-c77efa6a29a2"}
Response
{
  "data": {
    "systemPipelineCodeVersions": [
      {
        "owner": User,
        "version": "0.0.2",
        "description": "",
        "createdDate": "2023-03-08T09:21:14.261220",
        "code": [Code],
        "entrypointFilename": "BC_MCAM.pipeline.cwl"
      }
    ]
  }
}
Queries

systemPipelines

Description

List all system pipelines or steps from the catalogue

  1. Permissions required: pipeline-services/read on target system-pipeline
  2. UI contexts: 2.1. When user opens the Pipelines Dashboard page.
  3. Data returned: see listed field(s) of the response data type(s).
  4. Filter: list of system pipelines or steps available for the current user in the currently selected cluster
  5. Input variables: For full list of request structure see example query.
Response

Returns [SystemPipeline]!

Arguments
Name Description
type - Type What type of elements to list: PIPELINE or STEP
clusterId - ID Unique identifier of the cluster from there to search the available elements of the catalogue

Example

Query
query SystemPipelines(
  $type: Type,
  $clusterId: ID
) {
  systemPipelines(
    type: $type,
    clusterId: $clusterId
  ) {
    id
    name
    description
    version {
      latestVersion
      defaultVersion
      codeVersion {
        ...SystemPipelineCodeFragment
      }
    }
    owner {
      username
      displayName
      roles {
        ...RoleFragment
      }
    }
    labels
    createdDate
    lastModified
    clusterIds
    defaultExecutionEngine {
      name
      displayName
      status
    }
    allowedRoles
  }
}
Variables
{"type": "STEP", "clusterId": "c-m-m28vdqgf"}
Response
{
  "data": {
    "systemPipelines": [
      {
        "id": "94ce5c60-7c45-44d0-aa9e-430df28c87fe",
        "name": "BC_MCAM",
        "description": "This pipeline contains 2 steps: tm2raw_mcam and pds4_packager.",
        "version": SystemPipelineVersion,
        "owner": User,
        "labels": ["example-pipeline"],
        "createdDate": "2023-05-10T15:13:36.102336",
        "lastModified": "2023-05-10 15:14:23.097174",
        "clusterIds": ["c-m-m28vdqgf"],
        "defaultExecutionEngine": ExecutionEngine,
        "allowedRoles": ["pipeline-services/developer"]
      }
    ]
  }
}
Queries

systemVersion

Description

Get system version information.

  1. Access roles: none required
  2. UI contexts: 2.1. not used in the UI
  3. Data returned: see listed fields below.
  4. Filter: none
  5. Input arguments: none
Response

Returns a VersionInfo

Example

Query
query SystemVersion {
  systemVersion {
    version
    repository
  }
}
Response
{
  "data": {
    "systemVersion": {
      "version": "0.8.0",
      "repository": "On branch release/EDL-0.11.0\nYour branch is up-to-date with 'origin/release/EDL-0.11.0'.\nnothing to commit, working tree clean\n\n\ne3611107 Remove the comment inside the SVG\n2b9cda7f Fix DLNAME not avaialbe\nb49f47b9 Add a new service with readable name\n24ab16f5 Pull request #468: SEPPPCR-1512 Search app queries single app instead of all from rancher\n56d6753c SEPPPCR-1512 Search app queries single app instead of all from rancher\nbf8c3165 Remove the function to force the values\n727a0e33 SEPPPCR-1431: Fix resources when not having unig\ned6d1bb6 SEPPPCR-1431 Fix resources setup when the runtimeconfiguration was never set\n7479692a SEPPPCR-1431 Fix resources quota\n07d1dadb SEPPPCR-1431 Fix issue with milicore\n02bc0dde Pull request #455: Dld 20240212 hotfix\n0c750a6c SEPPPCR-1327&904 Update metadata field definition\nc8dba4ff SEPPPCR-1340 Add probes to the destroy\n5a66c008 SEPPPCR-1431 Fixing default CPU in milicore\n81727f23 Pull request #450: SEPPPCR-1446 Fix datalab access time on resume\n"
    }
  }
}

Mutations

addExecutionEngine

Description

Adds a new pipeline execution engine to database

  1. Permissions required: pipeline-services/create on target execution-engine
  2. UI contexts: not used in EDL UI
  3. Data created/updated: see listed field(s) of the response data type(s).
  4. Input variables: see list of arguments below for details.
  5. Response explanation: query response is successful if the fields requested are returned with values. Unsuccessful response contains null in data block and an additional "errors" block listing the errors that occurred
Response

Returns an ExecutionEngine!

Arguments
Name Description
input - ExecutionEngineInput Name and display name for the new execution engine of pipelines

Example

Query
mutation AddExecutionEngine($input: ExecutionEngineInput) {
  addExecutionEngine(input: $input) {
    name
    displayName
    status
  }
}
Variables
{"input": ExecutionEngineInput}
Response
{
  "data": {
    "addExecutionEngine": {
      "name": "CALRISSIAN",
      "displayName": "Calrissian",
      "status": "UP"
    }
  }
}
Mutations

addManagerToWorkspace

Description
  1. Permissions required: workspace-services/manage-manager on targetField workspaceName
  2. UI contexts: 2.1. When user clicks the "Select user" button on the "Users" modal window that open from the "Add manager" button on page "Team Members" 2.2. When user clicks the "promote to manager" button on the page "Team Members"
  3. Data created/updated: team and user connection with role manager is being created.
  4. Input variables: see list of arguments below for details
  5. Response explanation: True = adding the user as manager was successful. False = adding of the manager failed
Response

Returns a Boolean!

Arguments
Name Description
userId - ID! The unique identifier of the user being added as manager to the team (workspace)
workspaceName - ID! Unique 'Short name' of the team (workspace)
dataCentreId - ID! The unique identifier of the data centre where the team (workspace) is located

Example

Query
mutation AddManagerToWorkspace(
  $userId: ID!,
  $workspaceName: ID!,
  $dataCentreId: ID!
) {
  addManagerToWorkspace(
    userId: $userId,
    workspaceName: $workspaceName,
    dataCentreId: $dataCentreId
  )
}
Variables
{
  "userId": "etestuser",
  "workspaceName": "AWorkspaceTest2",
  "dataCentreId": "esadc01"
}
Response
{"data": {"addManagerToWorkspace": true}}
Mutations

addMemberToWorkspace

Description
  1. Permissions required: workspace-services/manage on targetField workspaceName
  2. UI contexts: 2.1. When user clicks the "Demote to regular member" button on the "Team Members" page 2.2. When user clicks the "Select user" button on the "Users" modal window that open from the "Add regular member" button on page "Team Members"
  3. Data created/updated: team and user in role member connection record is created in the database
  4. Input variables: see list of arguments below for details
  5. Response explanation: True = adding was successful. False = adding failed
Response

Returns a Boolean!

Arguments
Name Description
userId - ID! The unique identifier of the user being added as member to the team (workspace)
workspaceName - ID! Unique 'Short name' of the team (workspace)
dataCentreId - ID! The unique identifier of the data centre where the team (workspace) is located

Example

Query
mutation AddMemberToWorkspace(
  $userId: ID!,
  $workspaceName: ID!,
  $dataCentreId: ID!
) {
  addMemberToWorkspace(
    userId: $userId,
    workspaceName: $workspaceName,
    dataCentreId: $dataCentreId
  )
}
Variables
{
  "userId": "etestuser",
  "workspaceName": "AWorkspaceTest2",
  "dataCentreId": "esadc01"
}
Response
{"data": {"addMemberToWorkspace": false}}
Mutations

addPermissionToRole

Description

Assign a role to a permission

  1. Permissions required: "user-management/manage" on target "role"
  2. UI contexts: 2.1. When user clicks the "Select permission(s)" button on the Persmissons modal window.
  3. Data created/updated: Role and permissions connection(s) are added.
  4. Input variables: roleID, permissionID. see list of fields below for details.
  5. Response explanation: true = permission was successfully added to role.
Response

Returns a Boolean!

Arguments
Name Description
roleID - ID! Role unique identifier. Example: team/test
permissionID - ID! Permission unique identifier is composed of namespace/identifier/target. Example: data-volumes/gd/f

Example

Query
mutation AddPermissionToRole(
  $roleID: ID!,
  $permissionID: ID!
) {
  addPermissionToRole(
    roleID: $roleID,
    permissionID: $permissionID
  )
}
Variables
{
  "roleID": "workspace-services/team-member/TestLuisan",
  "permissionID": "data-volumes/gd/f"
}
Response
{"data": {"addPermissionToRole": true}}
Mutations

addRoleToUser

Description

Assign a user to a role

  1. Permissions required: permission "user-management/manage" on target "user"
  2. UI contexts: 2.1. When user clicks the "Select roles" button on the Roles modal window.
  3. Data created/updated: see listed field(s) of the response data type(s).
  4. Input variables: userID, roleID. see list of arguments below for details.
  5. Response explanation: true = role successfully added to user
Response

Returns a Boolean!

Arguments
Name Description
userID - ID! Unique identifier of user. Example: etestuser
roleID - ID! Unique identifier of role. Example: workspace-services/team-member/TestLuisan

Example

Query
mutation AddRoleToUser(
  $userID: ID!,
  $roleID: ID!
) {
  addRoleToUser(
    userID: $userID,
    roleID: $roleID
  )
}
Variables
{"userID": "etestuser", "roleID": "workspace-services/team-member/TestLuisan"}
Response
{"data": {"addRoleToUser": false}}
Mutations

addRolesToUsers

Description

Assign multiple users to multiple roles

  1. Permissions required: permission "user-management/manage" on target "user"
  2. UI contexts: not implemented in the UI
  3. Data created/updated: see listed field(s) of the response data type(s).
  4. Input variables: user_ids, role_ids. see list of arguments below for details.
  5. Response explanation: true = adding of multiple users to multiple roles was successful.
Response

Returns a Boolean!

Arguments
Name Description
user_ids - [ID!]! A list of user unique identifiers. Example: user_ids: ["op", "test"]
role_ids - [ID!]! A list of role unique identifiers. Example: role_ids: ["pipeline-services/developer","pipeline-services/example"]

Example

Query
mutation AddRolesToUsers(
  $user_ids: [ID!]!,
  $role_ids: [ID!]!
) {
  addRolesToUsers(
    user_ids: $user_ids,
    role_ids: $role_ids
  )
}
Variables
{
  "user_ids": ["etestuser"],
  "role_ids": ["pipeline-services/developer", "pipeline-services/example"]
}
Response
{"data": {"addRolesToUsers": false}}
Mutations

archiveBuild

Description

Allows to archive a datalab so it is no more visible Used in the share screen of the datalab details view You need to be developer and the owner of the datalab or operator Inputs: the build id, datalab will be infered based on it Outputs: the value of the BuildStatus, see the definition of BuildStatus

Response

Returns an Int!

Arguments
Name Description
build - ID!

Example

Query
mutation ArchiveBuild($build: ID!) {
  archiveBuild(build: $build)
}
Variables
{"build": "3d971341-136b-43e6-8298-bd8913edf77b"}
Response
{"data": {"archiveBuild": 987}}
Mutations

bookmarkBuild

Description

Mark a datalab as bookmarked to be placed in the bookmark section Used in the main screen You need to be logged in Inputs: the build id, datalab will be infered based on it bookmarked boolean will be True if the build is bookmarked or False if unbookmarked Outputs: True if everything went well

Response

Returns a Boolean

Arguments
Name Description
build - ID!
bookmarked - Boolean!

Example

Query
mutation BookmarkBuild(
  $build: ID!,
  $bookmarked: Boolean!
) {
  bookmarkBuild(
    build: $build,
    bookmarked: $bookmarked
  )
}
Variables
{"build": "buildid", "bookmarked": true}
Response
{"data": {"bookmarkBuild": true}}
Mutations

buildDatalab

Description

Trigger a build of the given datalab Used in testing screen of a given datalab You need to be developer and the owner of the datalab or operator Inputs: datalab the id of the datalab test flag to not trigger the real build but the initiating the flow Outputs: datalab build with the reference to the tekton build

Response

Returns a DatalabBuild

Arguments
Name Description
datalab - ID!
test - Boolean

Example

Query
mutation BuildDatalab(
  $datalab: ID!,
  $test: Boolean
) {
  buildDatalab(
    datalab: $datalab,
    test: $test
  ) {
    id
    datalabId
    version
    status
    runtimeConfiguration {
      cpuAllocation
      memAllocation
    }
    created_at
    buildRef
    scanRef
    logs
    progress
  }
}
Variables
{"datalab": "cdce7d27-fc5e-44da-b326-875624b6cbac", "test": true}
Response
{
  "data": {
    "buildDatalab": {
      "id": "3d971341-136b-43e6-8298-bd8913edf77b",
      "datalabId": "b27cda74-2db7-46ec-b287-a6353a47e74a",
      "version": "0.0.1-0",
      "status": "PUBLISHED",
      "runtimeConfiguration": RuntimeConfiguration,
      "created_at": "1715696521.537044",
      "buildRef": "sciapps-build-datalab-4ltcw",
      "scanRef": null,
      "logs": "Build started (sciapps-build-datalab-4ltcw)#!1715696521.539653!#Build ended with status BUILD_SUCCESS#!1715696617.206669!#Build marked as UNDER_MODERATION#!1715697174.958686!#Build marked as PUBLISHED#!1715697826.405907!#Approved#!1715697826.407465!#Datalab build published in the public catalog#!1715697848.135899!#Build archived#!1715773558.998771!#Build unarchived#!1715783367.895708!#Datalab build published in the public catalog#!1715783388.069154!#",
      "progress": "BUILD_SUCCESS"
    }
  }
}
Mutations

commentDatalab

Description

Add or update a comment on a datalab Used in the main screen You need to be logged in Inputs: the datalab id comment a string reprenting the comment Outputs: True if everything went well

Response

Returns a Boolean

Arguments
Name Description
datalab - ID!
comment - String

Example

Query
mutation CommentDatalab(
  $datalab: ID!,
  $comment: String
) {
  commentDatalab(
    datalab: $datalab,
    comment: $comment
  )
}
Variables
{"datalab": "cdce7d27-fc5e-44da-b326-875624b6cbac", "comment": "Great datalab!"}
Response
{"data": {"commentDatalab": true}}
Mutations

createDataVolume

Description

Create a new data volume that the user can mount and access.

  1. Requires permission: data-volumes/create on target data-volume
  2. UI contexts: 2.1. When user clicks "Add to my volumes" in the "Data Volume Settings" page.
  3. Data created/updated: a data volume that the user can mount and access from file browser or datalab or pipeline.
  4. Input variables: See DataVolumeInput for details.
  5. Output: see DataVolume for details.
Response

Returns a DataVolume

Arguments
Name Description
input - DataVolumeInput! Metadata input values for the datalab to be created

Example

Query
mutation CreateDataVolume($input: DataVolumeInput!) {
  createDataVolume(input: $input) {
    dvId
    name
    path
    url
    dataCentreIds
    clusterIds
    automount
  }
}
Variables
{"input": DataVolumeInput}
Response
{
  "data": {
    "createDataVolume": {
      "dvId": "a96cc3db403a7567",
      "name": "JWST - Public Data",
      "path": "jwst_jwst01_data",
      "url": "nfs://server1.volumes.datalabs.esa.int/jwst_jwst01_data",
      "dataCentreIds": ["*"],
      "clusterIds": ["c-m-m28vdqgf"],
      "automount": true
    }
  }
}
Mutations

createDatalabClass

Description

Create a draft datalab without any code or metadata Used in Datalab creation flow You need to be a developer Inputs: nothing Outputs: the id of the new datalab

Response

Returns an ID!

Example

Query
mutation CreateDatalabClass {
  createDatalabClass
}
Response
{
  "data": {
    "createDatalabClass": "95jsh18jec3vghow"
  }
}
Mutations

createDatalabInstance

Description

Instantiate a datalab package, returning a reference if successful

Response

Returns a Datalab

Arguments
Name Description
input - CreateDatalabInput!

Example

Query
mutation CreateDatalabInstance($input: CreateDatalabInput!) {
  createDatalabInstance(input: $input) {
    id
    dlp {
      id
      name
      image
      description
      config
      version
    }
    nodeUrl
    containerId
    name
    creation_time
    secret
    categories
    state
    details
    config
    resources {
      id
      dlId
      name
      type
      categories
      specification
      state
      details
    }
    launchRef
    clusterId
    last_access_time
  }
}
Variables
{"input": CreateDatalabInput}
Response
{
  "data": {
    "createDatalabInstance": {
      "id": "0cc7edf6-736b-42f6-891f-f395cc7896bc",
      "dlp": DatalabPackage,
      "nodeUrl": "",
      "containerId": "",
      "name": "jl-pipeman",
      "creation_time": "2025-01-14T12:15:30.062338",
      "secret": "cb3517e95b5cbacf",
      "categories": 1,
      "state": "running",
      "details": "",
      "config": null,
      "resources": [Resource],
      "launchRef": null,
      "clusterId": "c-m-m28vdqgf",
      "last_access_time": "2025-01-14T16:18:22.071397"
    }
  }
}
Mutations

createPermission

Description

Create a permission

  1. Permissions required: "user-management/create" on target "permission"
  2. UI contexts: 2.1. When user clicks the "Create Permission" button on the Permission Properties modal window.
  3. Data created/updated: see listed field(s) of the response data type(s).
  4. Input variables: description, id (example: "workspace-services/manage"), roles (["workspace-services/team-manager/dez16"]), target ("dez16")
  5. Response explanation: if the id is returned then the creation was successful.
Response

Returns a Permission!

Arguments
Name Description
input - CreatePermissionInput! Input variables structure for creating a permission record.

Example

Query
mutation CreatePermission($input: CreatePermissionInput!) {
  createPermission(input: $input) {
    id
    description
    target
  }
}
Variables
{"input": CreatePermissionInput}
Response
{
  "data": {
    "createPermission": {
      "id": "workspace-services/manage",
      "description": "Testing the permission creation for ICD documentation",
      "target": "dez6"
    }
  }
}
Mutations

createRole

Description

Create a role.

  1. Permissions required: permission "user-management/create" on target "role"
  2. UI contexts: 2.1. When user clicks the "Create role" button on the "Role Properties" modal window.
  3. Data created/updated: see listed field(s) of the response data type(s).
  4. Input variables: id (of the role to be created), members (to be added to the role), target (object name)
Response

Returns a Role!

Arguments
Name Description
input - CreateRoleInput! Elements needed to create a role: id, target, members

Example

Query
mutation CreateRole($input: CreateRoleInput!) {
  createRole(input: $input) {
    id
    description
    target
    permissions {
      id
      description
      target
    }
    cosmosLdapGroup
  }
}
Variables
{"input": CreateRoleInput}
Response
{
  "data": {
    "createRole": {
      "id": "resource-management/datalab",
      "description": "Datalab role on the jl-pipeman target with the namespace resource-management",
      "target": "jl-pipeman",
      "permissions": [Permission],
      "cosmosLdapGroup": "XYZ Datalabs Member"
    }
  }
}
Mutations

createSystemPipeline

Description

Promote a user pipeline or step to a system pipeline or step in the pipeline catalogue

  1. Permissions required: pipeline-services/create on target system-pipeline
  2. UI contexts: 2.1. When user clicks the Push button on the Push tab of the Pipeline Editor workspace cwl page.
  3. Data created/updated: see listed field(s) of the response data type(s).
  4. Input variables: see list of arguments below for details.
  5. Response explanation: query response is successful if the fields requested are returned with values. Unsuccessful response contains null in data block and an additional "errors" block listing the errors that occurred
Response

Returns a SystemPipeline!

Arguments
Name Description
input - SystemPipelineInput SYstem pipeline or step metadata needed for registering the pipeline or step in the catalogue

Example

Query
mutation CreateSystemPipeline($input: SystemPipelineInput) {
  createSystemPipeline(input: $input) {
    id
    name
    description
    version {
      latestVersion
      defaultVersion
      codeVersion {
        ...SystemPipelineCodeFragment
      }
    }
    owner {
      username
      displayName
      roles {
        ...RoleFragment
      }
    }
    labels
    createdDate
    lastModified
    clusterIds
    defaultExecutionEngine {
      name
      displayName
      status
    }
    allowedRoles
  }
}
Variables
{"input": SystemPipelineInput}
Response
{
  "data": {
    "createSystemPipeline": {
      "id": "94ce5c60-7c45-44d0-aa9e-430df28c87fe",
      "name": "BC_MCAM",
      "description": "This pipeline contains 2 steps: tm2raw_mcam and pds4_packager.",
      "version": SystemPipelineVersion,
      "owner": User,
      "labels": ["example-pipeline"],
      "createdDate": "2023-05-10T15:13:36.102336",
      "lastModified": "2023-05-10 15:14:23.097174",
      "clusterIds": ["c-m-m28vdqgf"],
      "defaultExecutionEngine": ExecutionEngine,
      "allowedRoles": ["pipeline-services/developer"]
    }
  }
}
Mutations

createWorkspace

Description
  1. Permissions required: workspace-services/create on target workspace
  2. UI contexts: 2.1. When user clicks the "Create Team" button on the "Team Workspace Settings" page/modal window.
  3. Data created/updated: see listed field(s) of the response data type(s).
  4. Input variables: see list of arguments below for details.
  5. Response explanation: if the response contain data of the workspace then the creation was successful.
Response

Returns a Workspace!

Arguments
Name Description
metadata - String! All the fields describing the Team. Like: Title, Short name, Domain, DCMI Type etc
dataCentreId - ID! Unique identifier of the data centre where the team is created

Example

Query
mutation CreateWorkspace(
  $metadata: String!,
  $dataCentreId: ID!
) {
  createWorkspace(
    metadata: $metadata,
    dataCentreId: $dataCentreId
  ) {
    workspaceID
    workspaceName
    metadata
    members {
      username
      displayName
      roles {
        ...RoleFragment
      }
    }
  }
}
Variables
{
  "metadata": "{\"title\":\"AWorkspaceTest2 title 1\",\"alternateName\":\"AWorkspaceTest2\",\"type\":\"https://data.esa.int/esado/Team\",\"description\":\"AWorkspaceTest2 description 1 AWorkspaceTest2 description 1 AWorkspaceTest2 description 1 AWorkspaceTest2 description 1 AWorkspaceTest2 description 1 AWorkspaceTest2 description 1\"}",
  "dataCentreId": "esadc01"
}
Response
{
  "data": {
    "createWorkspace": {
      "workspaceID": "55000",
      "workspaceName": "AWorkspaceTest2",
      "metadata": "{\"title\":\"AWorkspaceTest2 title 1\",\"alternateName\":\"AWorkspaceTest2\",\"type\":\"https://data.esa.int/esado/Team\",\"description\":\"AWorkspaceTest2 description 1 AWorkspaceTest2 description 1 AWorkspaceTest2 description 1 AWorkspaceTest2 description 1 AWorkspaceTest2 description 1 AWorkspaceTest2 description 1\"}",
      "members": [User]
    }
  }
}
Mutations

deleteAssets

Description

Delete assets

  1. Permissions required: permission discovery-services/manage-assets
  2. UI contexts: 2.1.User clicks on "Delete" button on the "Data Volume manager" page catalog item modal window. 2.2.User clicks on "Delete Team" button on the "Team members" page of a team.
  3. Data deleted: team (workspace) or dataset (catalog volume).
  4. Input variables: assetUri.
  5. Response explanation: if the response contains the assetUri and an empty messaege then the deletion was successful.
Response

Returns [ProcessingResult!]

Arguments
Name Description
assetUri - [ID!]! List of assets to be removed for the indices. Example: NbDWWLKvwyy8

Example

Query
mutation DeleteAssets($assetUri: [ID!]!) {
  deleteAssets(assetUri: $assetUri) {
    assetUri
    messages
  }
}
Variables
{"assetUri": ["NbDWWLKvwyy8"]}
Response
{"data": {"deleteAssets": [{"assetUri": "NbDWWLKvwyy8", "messages": []}]}}
Mutations

deleteDatalabsTrash

Description

Attempts to delete .Trash-$(UID) folders of all users from all clusters, these folders are created when user deletes files using jupyterlab built-in file-browser

Response

Returns a Boolean

Example

Query
mutation DeleteDatalabsTrash {
  deleteDatalabsTrash
}
Response
{"data": {"deleteDatalabsTrash": true}}
Mutations

deleteDeletedDatalabDirectories

Description

Attempts to delete already deleted datalab directories from user's workspace .home directory

Response

Returns a Boolean

Example

Query
mutation DeleteDeletedDatalabDirectories {
  deleteDeletedDatalabDirectories
}
Response
{"data": {"deleteDeletedDatalabDirectories": false}}
Mutations

deleteExecutionEngine

Description

Deletes execution engine from database

  1. Permissions required: pipeline-services/delete on target execution-engine
  2. UI contexts: not used in EDL UI
  3. Data created/updated: see listed field(s) of the response data type(s).
  4. Input variables: name of the pipeline execution engine that needs to be deleted
  5. Response explanation: true = pipeline execution engine successfully deleted
Response

Returns a Boolean!

Arguments
Name Description
name - String! Name of the pipeline execution engine that needs to be deleted

Example

Query
mutation DeleteExecutionEngine($name: String!) {
  deleteExecutionEngine(name: $name)
}
Variables
{"name": "CALRISSIAN"}
Response
{"data": {"deleteExecutionEngine": true}}
Mutations

deletePermission

Description

Delete a permission

  1. Permissions required: "user-management/delete" on target "permission"
  2. UI contexts: not implemented in the UI.
  3. Data deleted: permission record.
  4. Input variables: permissionID. see list of arguments below for details.
  5. Response explanation: true = deletion was successful.
Response

Returns a Boolean!

Arguments
Name Description
permissionID - ID! Permission unique identifier is composed of namespace/identifier/target. Example: workspace-services/manage/dez6

Example

Query
mutation DeletePermission($permissionID: ID!) {
  deletePermission(permissionID: $permissionID)
}
Variables
{"permissionID": "data-volumes/gd/f"}
Response
{"data": {"deletePermission": true}}
Mutations

deletePipelineRuns

Description

Delete one or more pipeline runs from history

  1. Permissions required: pipeline-services/launch on target system-pipeline
  2. UI contexts: 2.1. When user clicks the Delete button on the Pipeline dashboard page after selecting the pipeline run cards that need to be deleted
  3. Data created/updated: pipeline run records have been deleted from the database
  4. Input variables: ID-s of pipeline runs that need to be deleted
  5. Response explanation: successful response contains the id-s of the pipeline runs that were successfully deleted
Response

Returns [ID!]

Arguments
Name Description
input - DeletePipelineRunInput! ID-s of pipeline runs that need to be deleted

Example

Query
mutation DeletePipelineRuns($input: DeletePipelineRunInput!) {
  deletePipelineRuns(input: $input)
}
Variables
{"input": DeletePipelineRunInput}
Response
{
  "data": {
    "deletePipelineRuns": [
      "95jsh18jec3vghow"
    ]
  }
}
Mutations

deleteRole

Description

Delete a role

  1. Permissions required: "user-management/delete" on target "role"
  2. UI contexts: 2.1. Not implemented in the UI yet.
  3. Data created/updated: the role record specified has been deleted from EDL database
  4. Input variables: roleID
  5. Response explanation: Boolean = true - role was successfully deleted.
Response

Returns a Boolean!

Arguments
Name Description
roleID - ID! Unique identifier of the role to be deleted. Naming pattern: Role Namespace/Role Identifier

Example

Query
mutation DeleteRole($roleID: ID!) {
  deleteRole(roleID: $roleID)
}
Variables
{"roleID": "workspace-services/team-member/TestLuisan"}
Response
{"data": {"deleteRole": true}}
Mutations

deleteSystemPipeline

Description

Delete system pipeline from the pipeline catalogue

  1. Permissions required: pipeline-services/delete on target system-pipeline
  2. UI contexts: 2.1. When user clicks the Delete (Trash bin) button on the Pipeline Editor Catalogue page and clicks OK in the confirmation pop-up window.
  3. Data created/updated: see listed field(s) of the response data type(s).
  4. Input variables: see list of arguments below for details.
  5. Response explanation: if the data block in the response contains the id of the deleted system pipeline or step then the deletion was successful
Response

Returns an ID!

Arguments
Name Description
input - DeleteSystemPipelineInput Identifier of the system pipeline or step which needs to be deleted from the catalogue and optionally also the force flag

Example

Query
mutation DeleteSystemPipeline($input: DeleteSystemPipelineInput) {
  deleteSystemPipeline(input: $input)
}
Variables
{"input": DeleteSystemPipelineInput}
Response
{
  "data": {
    "deleteSystemPipeline": "95jsh18jec3vghow"
  }
}
Mutations

deleteWorkspace

Description
  1. Permissions required: workspace-services/delete on target workspace
  2. UI contexts: 2.1. When user clicks the "Delete Team" button on the "Team Members" page
  3. Data created/updated: team and related records are deleted from the database
  4. Input variables: see list of arguments below for details
  5. Response explanation: True = deletion was successful. False = deletion failed
Response

Returns a Boolean!

Arguments
Name Description
workspaceName - ID! Unique 'Short name' of the team (workspace)
dataCentreId - ID! The unique identifier of the data centre where the team (workspace) is located

Example

Query
mutation DeleteWorkspace(
  $workspaceName: ID!,
  $dataCentreId: ID!
) {
  deleteWorkspace(
    workspaceName: $workspaceName,
    dataCentreId: $dataCentreId
  )
}
Variables
{"workspaceName": "AWorkspaceTest2", "dataCentreId": "esadc01"}
Response
{"data": {"deleteWorkspace": true}}
Mutations

destroyBot

Description

Destroy a bot

  1. Permissions required: user-management/delete(bot)
  2. UI contexts: not implemented in UI
  3. Data created/updated: bot deleted.
  4. Input variables: see list of arguments below for details.
  5. Response explanation: true = bot successfully deleted
Response

Returns a Boolean

Arguments
Name Description
id - ID! Unique identifier of a bot. Example: 83bc47b09992c48d

Example

Query
mutation DestroyBot($id: ID!) {
  destroyBot(id: $id)
}
Variables
{"id": "83bc47b09992c48d"}
Response
{"data": {"destroyBot": true}}
Mutations

destroyDataVolume

Description

Destroy the specified data volume for the current user

  1. Requires permission: data-volumes/delete on target data-volume
  2. UI contexts: 2.1. When user clicks "OK" in the "Confirm deletion" page which open after clicking the Remove button on a data volume card on the page "Data Volumes".
  3. Data created/updated: a data volume metadata values are changed to what the user inserted on the page
  4. Input variables: data volume unique identifier.
  5. Output: true = volume was successfully deleted, false = volume was not deleted.
Response

Returns a Boolean

Arguments
Name Description
dvId - ID! The data volume unique identifier. Example: c1eaaf77401f299b

Example

Query
mutation DestroyDataVolume($dvId: ID!) {
  destroyDataVolume(dvId: $dvId)
}
Variables
{"dvId": "a96cc3db403a7567"}
Response
{"data": {"destroyDataVolume": true}}
Mutations

destroyDatalab

Description

Destroy a datalab

Response

Returns a Boolean

Arguments
Name Description
id - ID!

Example

Query
mutation DestroyDatalab($id: ID!) {
  destroyDatalab(id: $id)
}
Variables
{"id": "cdce7d27-fc5e-44da-b326-875624b6cbac"}
Response
{"data": {"destroyDatalab": false}}
Mutations

ensureFileBrowser

Description

Ensures 1 running file browser in user cluster

Response

Returns a Datalab!

Arguments
Name Description
clusterId - ID

Example

Query
mutation EnsureFileBrowser($clusterId: ID) {
  ensureFileBrowser(clusterId: $clusterId) {
    id
    dlp {
      id
      name
      image
      description
      config
      version
    }
    nodeUrl
    containerId
    name
    creation_time
    secret
    categories
    state
    details
    config
    resources {
      id
      dlId
      name
      type
      categories
      specification
      state
      details
    }
    launchRef
    clusterId
    last_access_time
  }
}
Variables
{"clusterId": "c-m-m28vdqgf"}
Response
{
  "data": {
    "ensureFileBrowser": {
      "id": "0cc7edf6-736b-42f6-891f-f395cc7896bc",
      "dlp": DatalabPackage,
      "nodeUrl": "",
      "containerId": "",
      "name": "jl-pipeman",
      "creation_time": "2025-01-14T12:15:30.062338",
      "secret": "cb3517e95b5cbacf",
      "categories": 1,
      "state": "running",
      "details": "",
      "config": null,
      "resources": [Resource],
      "launchRef": null,
      "clusterId": "c-m-m28vdqgf",
      "last_access_time": "2025-01-14T16:18:22.071397"
    }
  }
}
Mutations

grantAccess

Description

Allows a user to access a private datalab Used in the share screen of the datalab details view You need to be developer and the owner or operator Inputs: the datalab id user id to whome you give access Outputs: True if everything went well

Response

Returns a Boolean

Arguments
Name Description
datalabId - ID!
userId - String!

Example

Query
mutation GrantAccess(
  $datalabId: ID!,
  $userId: String!
) {
  grantAccess(
    datalabId: $datalabId,
    userId: $userId
  )
}
Variables
{"datalabId": "cdce7d27-fc5e-44da-b326-875624b6cbac", "userId": "etestuser"}
Response
{"data": {"grantAccess": false}}
Mutations

launchSystemPipelineRun

Description

Launch a system pipeline run, returning a PipelineRun object

  1. Permissions required: pipeline-services/launch on target system-pipeline
  2. UI contexts: 2.1. When user clicks the "Launch pipeline" button on the "Pipeline launch" page.
  3. Data created/updated: see listed field(s) of the response data type(s).
  4. Input variables: see list of arguments below for details.
  5. Response explanation: query response is successful if the fields requested are returned with values. Unsuccessful response contains null in data block and an additional "errors" block listing the errors that occurred
Response

Returns a PipelineRun!

Arguments
Name Description
input - SystemPipelineRunInput! System pipeline run defining input parameter values

Example

Query
mutation LaunchSystemPipelineRun($input: SystemPipelineRunInput!) {
  launchSystemPipelineRun(input: $input) {
    id
    owner {
      username
      displayName
      roles {
        ...RoleFragment
      }
    }
    pipeline {
      ... on UserPipeline {
        ...UserPipelineFragment
      }
      ... on SystemPipeline {
        ...SystemPipelineFragment
      }
    }
    identifier
    status
    totalStepCount
    steps {
      name
      startDate
      endDate
      logs {
        ...StepLogFragment
      }
      status
    }
    startDate
    endDate
    input {
      parameters {
        ...ParameterFragment
      }
    }
    output {
      outputPath
    }
    schedule {
      owner {
        ...UserFragment
      }
      cronExpression
      interval
    }
    notifications {
      email
      trigger
      triggerData {
        ...TriggerDataFragment
      }
    }
    defaultImage
    executionEngine {
      name
      displayName
      status
    }
    labels
    log {
      logs {
        ...LogFragment
      }
    }
    externalTrigger
    pipelineType
  }
}
Variables
{"input": SystemPipelineRunInput}
Response
{
  "data": {
    "launchSystemPipelineRun": {
      "id": "d94cafae-e907-47fd-9d41-23ef1798948c",
      "owner": User,
      "pipeline": UserPipeline,
      "identifier": "pipeline-run-test-2",
      "status": "COMPLETED",
      "totalStepCount": 0,
      "steps": [StepRun],
      "startDate": "2023-06-12T08:28:49.146531",
      "endDate": "2023-06-12T08:29:40.494027",
      "input": Input,
      "output": Output,
      "schedule": Schedule,
      "notifications": [Notification],
      "defaultImage": "",
      "executionEngine": ExecutionEngine,
      "labels": ["example-run"],
      "log": PipelineLog,
      "externalTrigger": true,
      "pipelineType": "USER"
    }
  }
}
Mutations

launchTestPipelineRun

Description

Launch a test pipeline run (from editor), returning a PipelineRun object

  1. Permissions required: pipeline-services/launch on target test-pipeline
  2. UI contexts: 2.1. When user clicks the 'Test pipeline' button on the Test page in the Pipeline Editor.
  3. Data created/updated: see listed field(s) of the response data type(s).
  4. Input variables: see list of arguments below for details.
  5. Response explanation: query response is successful if the fields requested are returned with values. Unsuccessful response contains null in data block and an additional "errors" block listing the errors that occurred
Response

Returns a PipelineRun!

Arguments
Name Description
input - TestPipelineRunInput! Input values used to run the test pipeline

Example

Query
mutation LaunchTestPipelineRun($input: TestPipelineRunInput!) {
  launchTestPipelineRun(input: $input) {
    id
    owner {
      username
      displayName
      roles {
        ...RoleFragment
      }
    }
    pipeline {
      ... on UserPipeline {
        ...UserPipelineFragment
      }
      ... on SystemPipeline {
        ...SystemPipelineFragment
      }
    }
    identifier
    status
    totalStepCount
    steps {
      name
      startDate
      endDate
      logs {
        ...StepLogFragment
      }
      status
    }
    startDate
    endDate
    input {
      parameters {
        ...ParameterFragment
      }
    }
    output {
      outputPath
    }
    schedule {
      owner {
        ...UserFragment
      }
      cronExpression
      interval
    }
    notifications {
      email
      trigger
      triggerData {
        ...TriggerDataFragment
      }
    }
    defaultImage
    executionEngine {
      name
      displayName
      status
    }
    labels
    log {
      logs {
        ...LogFragment
      }
    }
    externalTrigger
    pipelineType
  }
}
Variables
{"input": TestPipelineRunInput}
Response
{
  "data": {
    "launchTestPipelineRun": {
      "id": "d94cafae-e907-47fd-9d41-23ef1798948c",
      "owner": User,
      "pipeline": UserPipeline,
      "identifier": "pipeline-run-test-2",
      "status": "COMPLETED",
      "totalStepCount": 0,
      "steps": [StepRun],
      "startDate": "2023-06-12T08:28:49.146531",
      "endDate": "2023-06-12T08:29:40.494027",
      "input": Input,
      "output": Output,
      "schedule": Schedule,
      "notifications": [Notification],
      "defaultImage": "",
      "executionEngine": ExecutionEngine,
      "labels": ["example-run"],
      "log": PipelineLog,
      "externalTrigger": true,
      "pipelineType": "USER"
    }
  }
}
Mutations

launchUserPipelineRun

Description

Launch a user pipeline run, returning a PipelineRun object

  1. Permissions required: pipeline-services/launch on target user-pipeline
  2. UI contexts: 2.1. When user clicks the 'Launch pipeline' button on the Pipeline launch page after navigating to it via the 'Browse User pipeline' button".
  3. Data created/updated: see listed field(s) of the response data type(s).
  4. Input variables: see list of arguments below for details.
  5. Response explanation: query response is successful if the fields requested are returned with values. Unsuccessful response contains null in data block and an additional "errors" block listing the errors that occurred
Response

Returns a PipelineRun!

Arguments
Name Description
input - UserPipelineRunInput! User pipeline run defining input parameter values

Example

Query
mutation LaunchUserPipelineRun($input: UserPipelineRunInput!) {
  launchUserPipelineRun(input: $input) {
    id
    owner {
      username
      displayName
      roles {
        ...RoleFragment
      }
    }
    pipeline {
      ... on UserPipeline {
        ...UserPipelineFragment
      }
      ... on SystemPipeline {
        ...SystemPipelineFragment
      }
    }
    identifier
    status
    totalStepCount
    steps {
      name
      startDate
      endDate
      logs {
        ...StepLogFragment
      }
      status
    }
    startDate
    endDate
    input {
      parameters {
        ...ParameterFragment
      }
    }
    output {
      outputPath
    }
    schedule {
      owner {
        ...UserFragment
      }
      cronExpression
      interval
    }
    notifications {
      email
      trigger
      triggerData {
        ...TriggerDataFragment
      }
    }
    defaultImage
    executionEngine {
      name
      displayName
      status
    }
    labels
    log {
      logs {
        ...LogFragment
      }
    }
    externalTrigger
    pipelineType
  }
}
Variables
{"input": UserPipelineRunInput}
Response
{
  "data": {
    "launchUserPipelineRun": {
      "id": "d94cafae-e907-47fd-9d41-23ef1798948c",
      "owner": User,
      "pipeline": UserPipeline,
      "identifier": "pipeline-run-test-2",
      "status": "COMPLETED",
      "totalStepCount": 0,
      "steps": [StepRun],
      "startDate": "2023-06-12T08:28:49.146531",
      "endDate": "2023-06-12T08:29:40.494027",
      "input": Input,
      "output": Output,
      "schedule": Schedule,
      "notifications": [Notification],
      "defaultImage": "",
      "executionEngine": ExecutionEngine,
      "labels": ["example-run"],
      "log": PipelineLog,
      "externalTrigger": true,
      "pipelineType": "USER"
    }
  }
}
Mutations

mountDataVolume

Description

Mount the specified data volume at the given datalab for the current user

  1. Requires permission: data-volumes/mount on target data-volume
  2. UI contexts: 2.1. When user launches a datalab. 2.2. When user adds a data volume so that it is set to be automounted and a datalab is running.
  3. Data created/updated: a data volume is made accessible in a datalab
  4. Input variables: data volume unique identifier, datalab unique identifier.
  5. Output: true = volume was successfully mounted, false = volume was not mounted.
Response

Returns a Boolean

Arguments
Name Description
dvId - ID! The data volume unique identifier
dlId - ID! The datalab unique identifier

Example

Query
mutation MountDataVolume(
  $dvId: ID!,
  $dlId: ID!
) {
  mountDataVolume(
    dvId: $dvId,
    dlId: $dlId
  )
}
Variables
{"dvId": "a96cc3db403a7567", "dlId": "66f73b66fb154e02"}
Response
{"data": {"mountDataVolume": true}}
Mutations

nonce

Description

Get a Nonce

  1. Permissions required: none required
  2. UI contexts: not implemented in UI
  3. Data created/updated: nonce record created. see listed field(s) of the response data type(s).
  4. Input variables: id of a bot. See a list of arguments below for details.
  5. Response explanation: the nonce string is being returned. Example: 0bfd9fb04eff82a5
Response

Returns a String

Arguments
Name Description
id - ID! Unique identifier of a bot. Example: 83bc47b09992c48d

Example

Query
mutation Nonce($id: ID!) {
  nonce(id: $id)
}
Variables
{"id": "83bc47b09992c48d"}
Response
{"data": {"nonce": "some-value"}}
Mutations

pauseDatalab

Description

Scales datalab deployment to 0

Response

Returns a Boolean

Arguments
Name Description
id - ID!

Example

Query
mutation PauseDatalab($id: ID!) {
  pauseDatalab(id: $id)
}
Variables
{"id": "cdce7d27-fc5e-44da-b326-875624b6cbac"}
Response
{"data": {"pauseDatalab": false}}
Mutations

publishBuild

Description

Allows to publish a datalab build Used in the share screen of the datalab details view You need to be developer to publish Inputs: the build id, datalab will be infered based on it test will disable the tekton pipeline to save resources Outputs: the value of the BuildStatus, see the definition of BuildStatus

Response

Returns an Int!

Arguments
Name Description
build - ID!
test - Boolean

Example

Query
mutation PublishBuild(
  $build: ID!,
  $test: Boolean
) {
  publishBuild(
    build: $build,
    test: $test
  )
}
Variables
{"build": "3d971341-136b-43e6-8298-bd8913edf77b", "test": false}
Response
{"data": {"publishBuild": 123}}
Mutations

refreshCatalogs

Description

Refreshes Rancher Catalogs by specific repository type in all clusters. This is for internal use only by a robot user.

Response

Returns a Boolean

Arguments
Name Description
type - String!

Example

Query
mutation RefreshCatalogs($type: String!) {
  refreshCatalogs(type: $type)
}
Variables
{"type": "system"}
Response
{"data": {"refreshCatalogs": true}}
Mutations

removeDatalab

Description

Delete a datalab, we are only adding a flag, nothing is really removed Used in Datalab details screen in the sidebar You need to be developer and the owner of the datalab or operator Inputs: the id of the datalab Outputs: datalab delete

Response

Returns a DatalabClass

Arguments
Name Description
datalab - ID!

Example

Query
mutation RemoveDatalab($datalab: ID!) {
  removeDatalab(datalab: $datalab) {
    id
    owner {
      username
      displayName
      roles {
        ...RoleFragment
      }
    }
    is_public
    created_at
    modified_at
    repository
    branch
    artefact
    status
    name
    description
    icon
    runtimeConfiguration {
      cpuAllocation
      memAllocation
    }
    metadata {
      name
      value
      definition {
        ...MetadataEntryDefinitionFragment
      }
    }
    nstars
    version
  }
}
Variables
{"datalab": "cdce7d27-fc5e-44da-b326-875624b6cbac"}
Response
{
  "data": {
    "removeDatalab": {
      "id": "deaef60e-bde6-4ca8-b284-79b03db417b2",
      "owner": User,
      "is_public": false,
      "created_at": "1715163378.021328",
      "modified_at": "1715163471.601883",
      "repository": null,
      "branch": null,
      "artefact": null,
      "status": "DRAFT",
      "name": "testing-lab",
      "description": "A test",
      "icon": null,
      "runtimeConfiguration": RuntimeConfiguration,
      "metadata": [MetadataEntry],
      "nstars": 0,
      "version": "0.0.1"
    }
  }
}
Mutations

removeManagerFromWorkspace

Description
  1. Permissions required: workspace-services/manage-manager on targetField workspaceName
  2. UI contexts: 2.1. When user clicks the "Remove user" or "Demote to regular member" button on the "Team Members" page
  3. Data created/updated: team and user connection in the role of manager is deleted from the database
  4. Input variables: see list of arguments below for details
  5. Response explanation: True = manager removal was successful. False = removal failed
Response

Returns a Boolean!

Arguments
Name Description
userId - ID! The unique identifier of the user being removed as manager from the team (workspace)
workspaceName - ID! Unique 'Short name' of the team (workspace)
dataCentreId - ID! The unique identifier of the data centre where the team (workspace) is located

Example

Query
mutation RemoveManagerFromWorkspace(
  $userId: ID!,
  $workspaceName: ID!,
  $dataCentreId: ID!
) {
  removeManagerFromWorkspace(
    userId: $userId,
    workspaceName: $workspaceName,
    dataCentreId: $dataCentreId
  )
}
Variables
{
  "userId": "etestuser",
  "workspaceName": "AWorkspaceTest2",
  "dataCentreId": "esadc01"
}
Response
{"data": {"removeManagerFromWorkspace": false}}
Mutations

removeMemberFromWorkspace

Description
  1. Permissions required: workspace-services/manage on targetField workspaceName
  2. UI contexts: 2.1. When user clicks the "remove user" button on the "Team Members" page
  3. Data created/updated: team and user in role member connection is deleted from the database
  4. Input variables: see list of arguments below for details
  5. Response explanation: True = removal was successful. False = removal failed
Response

Returns a Boolean!

Arguments
Name Description
userId - ID! The unique identifier of the user being removed as member from the team (workspace)
workspaceName - ID! Unique 'Short name' of the team (workspace)
dataCentreId - ID! The unique identifier of the data centre where the team (workspace) is located

Example

Query
mutation RemoveMemberFromWorkspace(
  $userId: ID!,
  $workspaceName: ID!,
  $dataCentreId: ID!
) {
  removeMemberFromWorkspace(
    userId: $userId,
    workspaceName: $workspaceName,
    dataCentreId: $dataCentreId
  )
}
Variables
{
  "userId": "etestuser",
  "workspaceName": "AWorkspaceTest2",
  "dataCentreId": "esadc01"
}
Response
{"data": {"removeMemberFromWorkspace": false}}
Mutations

removePermissionFromRole

Description

Remove a role from a permission

  1. Permissions required: "user-management/manage" on target "role"
  2. UI contexts: 2.1. When user clicks the Trash bin button on the in the block Permissions on the page "Access Control".
  3. Data changed: Role connection to permission has been deleted.
  4. Input variables: roleID, permissionID. see list of fields below for details.
  5. Response explanation: true = permission was successfully remvoed from the role.
Response

Returns a Boolean!

Arguments
Name Description
roleID - ID! Role unique identifier. Example: team/test
permissionID - ID! Permission unique identifier is composed of namespace/identifier/target. Example: data-volumes/gd/f

Example

Query
mutation RemovePermissionFromRole(
  $roleID: ID!,
  $permissionID: ID!
) {
  removePermissionFromRole(
    roleID: $roleID,
    permissionID: $permissionID
  )
}
Variables
{
  "roleID": "workspace-services/team-member/TestLuisan",
  "permissionID": "data-volumes/gd/f"
}
Response
{"data": {"removePermissionFromRole": true}}
Mutations

removeRoleFromUser

Description

Remove a user from a role

  1. Permissions required: permission "user-management/manage" on target "user"
  2. UI contexts: 2.1.User clicks the Trash bin button next to a role in the block Roles on the page User Management.
  3. Data created/updated: The connection between the user and the role is deleted.
  4. Input variables: see list of fields below for details.
  5. Response explanation: true = removal of the connection between role and user was successful.
Response

Returns a Boolean!

Arguments
Name Description
userID - ID! Unique identifier of user. Example: etestuser
roleID - ID! Unique identifier of role. Example: workspace-services/team-member/TestLuisan

Example

Query
mutation RemoveRoleFromUser(
  $userID: ID!,
  $roleID: ID!
) {
  removeRoleFromUser(
    userID: $userID,
    roleID: $roleID
  )
}
Variables
{"userID": "etestuser", "roleID": "workspace-services/team-member/TestLuisan"}
Response
{"data": {"removeRoleFromUser": true}}
Mutations

renameWorkspace

Description
  1. Permissions required: workspace-services/update on target workspace
  2. UI contexts: not used in UI
  3. Data created/updated: see listed field(s) of the response data type(s).
  4. Input variables: see list of arguments below for details.
  5. Response explanation: True - workspace was successfully renamed. False - workspace name change failed.
Response

Returns a Boolean!

Arguments
Name Description
currentName - String The current team (workspace) 'Short name'
newName - String The new 'Short name' for the workspace
dataCentreId - ID! The unique ID of the data centre where the team (workspace) is located

Example

Query
mutation RenameWorkspace(
  $currentName: String,
  $newName: String,
  $dataCentreId: ID!
) {
  renameWorkspace(
    currentName: $currentName,
    newName: $newName,
    dataCentreId: $dataCentreId
  )
}
Variables
{
  "currentName": "AWorkspaceTest2",
  "newName": "AWorkspaceTest3",
  "dataCentreId": "esadc01"
}
Response
{"data": {"renameWorkspace": false}}
Mutations

resumeDatalab

Description

Scales datalab deployment to 1

Response

Returns a Boolean

Arguments
Name Description
id - ID!

Example

Query
mutation ResumeDatalab($id: ID!) {
  resumeDatalab(id: $id)
}
Variables
{"id": "cdce7d27-fc5e-44da-b326-875624b6cbac"}
Response
{"data": {"resumeDatalab": true}}
Mutations

revokeAccess

Description

Allows a user to remove access to a private datalab Used in the share screen of the datalab details view You need to be developer and the owner or operator Inputs: the datalab id user id to whome you remove access Outputs: True if everything went well

Response

Returns a Boolean

Arguments
Name Description
datalabId - ID!
userId - String!

Example

Query
mutation RevokeAccess(
  $datalabId: ID!,
  $userId: String!
) {
  revokeAccess(
    datalabId: $datalabId,
    userId: $userId
  )
}
Variables
{"datalabId": "0cc7edf6-736b-42f6-891f-f395cc7896bc", "userId": "etestuser"}
Response
{"data": {"revokeAccess": true}}
Mutations

revokeBuildModerationRequest

Description

Allows to revoke the publication of a datalab before it was approved Used in the share screen of the datalab details view You need to be developer and the owner of the datalab or operator Inputs: the build id, datalab will be infered based on it Outputs: the value of the BuildStatus, see the definition of BuildStatus

Response

Returns an Int!

Arguments
Name Description
build - ID!

Example

Query
mutation RevokeBuildModerationRequest($build: ID!) {
  revokeBuildModerationRequest(build: $build)
}
Variables
{"build": "3d971341-136b-43e6-8298-bd8913edf77b"}
Response
{"data": {"revokeBuildModerationRequest": 987}}
Mutations

scanDatalabBuild

Description

Run the security scan on the docker image associated to the datalab Used in Datalab testing screen when available scan logs will be in fetch from the UI using the monitorLog subscription You need to be moderator to run that scan Input: the build id, that's the one holding the right version of the docker image Outputs: the datalab build with a status

Response

Returns a DatalabBuild

Arguments
Name Description
build - ID!

Example

Query
mutation ScanDatalabBuild($build: ID!) {
  scanDatalabBuild(build: $build) {
    id
    datalabId
    version
    status
    runtimeConfiguration {
      cpuAllocation
      memAllocation
    }
    created_at
    buildRef
    scanRef
    logs
    progress
  }
}
Variables
{"build": "3d971341-136b-43e6-8298-bd8913edf77b"}
Response
{
  "data": {
    "scanDatalabBuild": {
      "id": "3d971341-136b-43e6-8298-bd8913edf77b",
      "datalabId": "b27cda74-2db7-46ec-b287-a6353a47e74a",
      "version": "0.0.1-0",
      "status": "PUBLISHED",
      "runtimeConfiguration": RuntimeConfiguration,
      "created_at": "1715696521.537044",
      "buildRef": "sciapps-build-datalab-4ltcw",
      "scanRef": null,
      "logs": "Build started (sciapps-build-datalab-4ltcw)#!1715696521.539653!#Build ended with status BUILD_SUCCESS#!1715696617.206669!#Build marked as UNDER_MODERATION#!1715697174.958686!#Build marked as PUBLISHED#!1715697826.405907!#Approved#!1715697826.407465!#Datalab build published in the public catalog#!1715697848.135899!#Build archived#!1715773558.998771!#Build unarchived#!1715783367.895708!#Datalab build published in the public catalog#!1715783388.069154!#",
      "progress": "BUILD_SUCCESS"
    }
  }
}
Mutations

setDatalabBuildRuntimeData

Description

Set the datalab default runtime configuration Used in main screen and testing screen when launching a datalab This is done every time the developer is running its datalab but only made available when published You need to be developer and the owner of the datalab Inputs: build the id of the datalab build runtime configuration is the resources needed to run the datalab build. See RuntimeConfigurationInput for more details cluster_id is not used Outputs: boolean true if everything went well

Response

Returns a Boolean

Arguments
Name Description
build - ID!
runtime_configuration - RuntimeConfigurationInput!
cluster_id - ID!

Example

Query
mutation SetDatalabBuildRuntimeData(
  $build: ID!,
  $runtime_configuration: RuntimeConfigurationInput!,
  $cluster_id: ID!
) {
  setDatalabBuildRuntimeData(
    build: $build,
    runtime_configuration: $runtime_configuration,
    cluster_id: $cluster_id
  )
}
Variables
{
  "build": "3d971341-136b-43e6-8298-bd8913edf77b",
  "runtime_configuration": RuntimeConfigurationInput,
  "cluster_id": "c-m-m28vdqgf"
}
Response
{"data": {"setDatalabBuildRuntimeData": true}}
Mutations

setDatalabClusters

Description

Set clusters where this datalab is available Used in Datalab creation flow You need to be a developer and the owner of the datalab Inputs: datalab the id of the datalab cluster_ids the list of cluster id Outputs: boolean true if everything went well

Response

Returns a Boolean

Arguments
Name Description
datalab - ID!
cluster_ids - [ID!]!

Example

Query
mutation SetDatalabClusters(
  $datalab: ID!,
  $cluster_ids: [ID!]!
) {
  setDatalabClusters(
    datalab: $datalab,
    cluster_ids: $cluster_ids
  )
}
Variables
{
  "datalab": "cdce7d27-fc5e-44da-b326-875624b6cbac",
  "cluster_ids": ["c-m-m28vdqgf"]
}
Response
{"data": {"setDatalabClusters": true}}
Mutations

setDatalabMetadataEntries

Description

Update the metadata of a datalab Used in Datalab creation flow and update flow in metadata screen You need to be developer and the owner of the datalab or operator to update the metadata Inputs: datalab the id of the datalab to udpate entried the entire set of metadata for the datalab, no partial update. Outputs: the datalab updated

Response

Returns a DatalabClass

Arguments
Name Description
datalab - ID!
entries - [MetadataEntryInput!]!

Example

Query
mutation SetDatalabMetadataEntries(
  $datalab: ID!,
  $entries: [MetadataEntryInput!]!
) {
  setDatalabMetadataEntries(
    datalab: $datalab,
    entries: $entries
  ) {
    id
    owner {
      username
      displayName
      roles {
        ...RoleFragment
      }
    }
    is_public
    created_at
    modified_at
    repository
    branch
    artefact
    status
    name
    description
    icon
    runtimeConfiguration {
      cpuAllocation
      memAllocation
    }
    metadata {
      name
      value
      definition {
        ...MetadataEntryDefinitionFragment
      }
    }
    nstars
    version
  }
}
Variables
{
  "datalab": "cdce7d27-fc5e-44da-b326-875624b6cbac",
  "entries": [MetadataEntryInput]
}
Response
{
  "data": {
    "setDatalabMetadataEntries": {
      "id": "deaef60e-bde6-4ca8-b284-79b03db417b2",
      "owner": User,
      "is_public": false,
      "created_at": "1715163378.021328",
      "modified_at": "1715163471.601883",
      "repository": null,
      "branch": null,
      "artefact": null,
      "status": "DRAFT",
      "name": "testing-lab",
      "description": "A test",
      "icon": null,
      "runtimeConfiguration": RuntimeConfiguration,
      "metadata": [MetadataEntry],
      "nstars": 0,
      "version": "0.0.1"
    }
  }
}
Mutations

setDatalabRepository

Description

Set the Git repository to the new datalab Used in Datalab creation flow You need to be a developer and the owner of the datalab Inputs: datalab the id of the datalab repository the url of the public repository branch the branch to clone on the repository Outputs: boolean true if everything went well

Response

Returns a Boolean

Arguments
Name Description
datalab - ID!
repository - String!
branch - String

Example

Query
mutation SetDatalabRepository(
  $datalab: ID!,
  $repository: String!,
  $branch: String
) {
  setDatalabRepository(
    datalab: $datalab,
    repository: $repository,
    branch: $branch
  )
}
Variables
{
  "datalab": "cdce7d27-fc5e-44da-b326-875624b6cbac",
  "repository": "",
  "branch": null
}
Response
{"data": {"setDatalabRepository": true}}
Mutations

setDatalabState

Description

Set the state of a datalab.

Response

Returns a Boolean

Arguments
Name Description
state - String

Example

Query
mutation SetDatalabState($state: String) {
  setDatalabState(state: $state)
}
Variables
{"state": "running"}
Response
{"data": {"setDatalabState": true}}
Mutations

setDatalabType

Description

Set the type of datalab jl or x depending if is based on jupyter or vnc Used in Datalab creation flow The type of datalab is important as in drives the interface to connect to, for web server use JL You need to be developer and the owner of the datalab Inputs: datalab the id of the datalab type a string letters jl or x Outputs: boolean true if everything went well

Response

Returns a Boolean

Arguments
Name Description
datalab - ID!
type - String!

Example

Query
mutation SetDatalabType(
  $datalab: ID!,
  $type: String!
) {
  setDatalabType(
    datalab: $datalab,
    type: $type
  )
}
Variables
{"datalab": "cdce7d27-fc5e-44da-b326-875624b6cbac", "type": "jl"}
Response
{"data": {"setDatalabType": false}}
Mutations

setLogLevel

Description

Adjust log level for a system module

Response

Returns a Boolean

Arguments
Name Description
module - String! Full module path
level - LogLevel! Log level

Example

Query
mutation SetLogLevel(
  $module: String!,
  $level: LogLevel!
) {
  setLogLevel(
    module: $module,
    level: $level
  )
}
Variables
{"module": "some-value", "level": "NOTSET"}
Response
{"data": {"setLogLevel": true}}
Mutations

setResourceState

Response

Returns a Boolean

Arguments
Name Description
id - ID!
state - ResourceState!
details - String

Example

Query
mutation SetResourceState(
  $id: ID!,
  $state: ResourceState!,
  $details: String
) {
  setResourceState(
    id: $id,
    state: $state,
    details: $details
  )
}
Variables
{"id": "e6a455ff90f27315", "state": "READY", "details": ""}
Response
{"data": {"setResourceState": false}}
Mutations

stopPipelineRun

Description

Kill pipeline run

  1. Permissions required: pipeline-services/launch on target system-pipeline
  2. UI contexts: 2.1. When user clicks the 'Stop pipeline run' button on the Pipeline dashboard in the corner of a pipeline run card.
  3. Data created/updated: see listed field(s) of the response data type(s).
  4. Input variables: see list of arguments below for details.
  5. Response explanation: query response is successful if the data block contains the same unique identifier of the pipeline run that was in the input
Response

Returns a PipelineRun!

Arguments
Name Description
input - StopPipelineRunInput! Unique identifier of the pipeline run that needs to be stopped

Example

Query
mutation StopPipelineRun($input: StopPipelineRunInput!) {
  stopPipelineRun(input: $input) {
    id
    owner {
      username
      displayName
      roles {
        ...RoleFragment
      }
    }
    pipeline {
      ... on UserPipeline {
        ...UserPipelineFragment
      }
      ... on SystemPipeline {
        ...SystemPipelineFragment
      }
    }
    identifier
    status
    totalStepCount
    steps {
      name
      startDate
      endDate
      logs {
        ...StepLogFragment
      }
      status
    }
    startDate
    endDate
    input {
      parameters {
        ...ParameterFragment
      }
    }
    output {
      outputPath
    }
    schedule {
      owner {
        ...UserFragment
      }
      cronExpression
      interval
    }
    notifications {
      email
      trigger
      triggerData {
        ...TriggerDataFragment
      }
    }
    defaultImage
    executionEngine {
      name
      displayName
      status
    }
    labels
    log {
      logs {
        ...LogFragment
      }
    }
    externalTrigger
    pipelineType
  }
}
Variables
{"input": StopPipelineRunInput}
Response
{
  "data": {
    "stopPipelineRun": {
      "id": "d94cafae-e907-47fd-9d41-23ef1798948c",
      "owner": User,
      "pipeline": UserPipeline,
      "identifier": "pipeline-run-test-2",
      "status": "COMPLETED",
      "totalStepCount": 0,
      "steps": [StepRun],
      "startDate": "2023-06-12T08:28:49.146531",
      "endDate": "2023-06-12T08:29:40.494027",
      "input": Input,
      "output": Output,
      "schedule": Schedule,
      "notifications": [Notification],
      "defaultImage": "",
      "executionEngine": ExecutionEngine,
      "labels": ["example-run"],
      "log": PipelineLog,
      "externalTrigger": true,
      "pipelineType": "USER"
    }
  }
}
Mutations

synchronizeUser

Description

Synchronizes a user with the external system and returns user details.

This mutation:

  1. Synchronizes the user with Cosmos LDAP.
  2. Runs workspace setup commands for new users.
  3. Ensures the user's file-browser has been deployed in the target cluster.
  4. Creates a new session for the user which can be used by the external system.
  5. Caches the user details in Redis to optimize subsequent requests.

Mutation first checks if session data for the given user and external system has been cached. If cached data exists, it returns it. Otherwise, it acquires a lock to ensure the mutation does not run too frequently, performs synchronization and session creation and caches the result in Redis. Session expires in 1h and also cached session data lives for 1h.

Response

Returns a UserDetails!

Arguments
Name Description
username - String!
clusterId - ID!

Example

Query
mutation SynchronizeUser(
  $username: String!,
  $clusterId: ID!
) {
  synchronizeUser(
    username: $username,
    clusterId: $clusterId
  ) {
    userSession {
      session
      expiryDate
    }
    user
    workspace {
      uid
      gid
      path
      url
    }
  }
}
Variables
{"username": "etestuser", "clusterId": "c-m-m28vdqgf"}
Response
{
  "data": {
    "synchronizeUser": {
      "userSession": UserSession,
      "user": "etestuser",
      "workspace": UserWorkspace
    }
  }
}
Mutations

transferDatalabOwnership

Description

Transfer ownership of a datalab to a new user. Used in datalab management screen. You need to be an operator to perform this operation. Inputs: the datalab ID of the datalab to transfer the user ID of the user who will become the new owner Outputs: boolean true if the transfer was successful

Response

Returns a Boolean

Arguments
Name Description
datalabId - ID!
newOwnerId - ID!

Example

Query
mutation TransferDatalabOwnership(
  $datalabId: ID!,
  $newOwnerId: ID!
) {
  transferDatalabOwnership(
    datalabId: $datalabId,
    newOwnerId: $newOwnerId
  )
}
Variables
{
  "datalabId": "3d971341-136b-43e6-8298-bd8913edf77b",
  "newOwnerId": "new-owner-user"
}
Response
{"data": {"transferDatalabOwnership": false}}
Mutations

unarchiveBuild

Description

Allows to revoke the archive state of a datalab Used in the share screen of the datalab details view You need to be developer and the owner of the datalab or operator Inputs: the build id, datalab will be infered based on it Outputs: the value of the BuildStatus, see the definition of BuildStatus

Response

Returns an Int!

Arguments
Name Description
build - ID!

Example

Query
mutation UnarchiveBuild($build: ID!) {
  unarchiveBuild(build: $build)
}
Variables
{"build": "3d971341-136b-43e6-8298-bd8913edf77b"}
Response
{"data": {"unarchiveBuild": 987}}
Mutations

unmountDataVolume

Description

Unmount the specified data volume from the given datalab for the current user

  1. Requires permission: data-volumes/unmount on target data-volume
  2. UI contexts: 2.1. When user deletes a datalab. 2.2. When user uses the (terminal) command unmount inside the datalab.
  3. Data created/updated: acces to a data volume is removed from a datalab
  4. Input variables: data volume resource identifier. Resource ID-s for data volumes are datalab specific can be found for example in the response of the query "datalabs" under "resources" block of each datalab.
  5. Output: true = volume was successfully unmounted, false = volume was not unmounted.
Response

Returns a Boolean

Arguments
Name Description
resId - ID! The data volume as a datalab specific resource identifier

Example

Query
mutation UnmountDataVolume($resId: ID!) {
  unmountDataVolume(resId: $resId)
}
Variables
{"resId": "e6a455ff90f27315"}
Response
{"data": {"unmountDataVolume": true}}
Mutations

updateAnnouncement

Description

Updates the announcement

  1. Permissions required: user-management/update-announcement on target announcement
  2. UI contexts: 2.1. Not used in the UI.
  3. Data created/updated: see listed field(s) of the response data type(s).
  4. Input variables: see list of arguments below for details.
  5. Response explanation: If the response contains the data sent to the endpoint then the update of the announcement was successful.
Response

Returns an Announcement!

Arguments
Name Description
input - UpdateAnnouncementInput! See details in the linked UpdateAnnouncementInput data type

Example

Query
mutation UpdateAnnouncement($input: UpdateAnnouncementInput!) {
  updateAnnouncement(input: $input) {
    announcement
    textColorCode
    backgroundColorCode
    createdTime
  }
}
Variables
{"input": UpdateAnnouncementInput}
Response
{
  "data": {
    "updateAnnouncement": {
      "announcement": "<br><center>Banner text update test 1</center></br>",
      "textColorCode": "#00008B",
      "backgroundColorCode": "#50EBEC",
      "createdTime": "2024-04-24T13:57:35.621599"
    }
  }
}
Mutations

updateDataVolume

Description

Update the metadata for a custom data volume

  1. Requires permission: data-volumes/manage on target data-volume
  2. UI contexts: 2.1. When user clicks "Update data volume" in the "Data Volume Settings" page.
  3. Data created/updated: a data volume metadata values are changed to what the user inserted on the page.
  4. Input variables: See DataVolumeInput for details.
  5. Output: see DataVolume for details.
Response

Returns a DataVolume

Arguments
Name Description
dvId - ID! The data volume identifier
volumeInput - DataVolumeInput! Updated metadata for a custom data volume

Example

Query
mutation UpdateDataVolume(
  $dvId: ID!,
  $volumeInput: DataVolumeInput!
) {
  updateDataVolume(
    dvId: $dvId,
    volumeInput: $volumeInput
  ) {
    dvId
    name
    path
    url
    dataCentreIds
    clusterIds
    automount
  }
}
Variables
{
  "dvId": "a96cc3db403a7567",
  "volumeInput": DataVolumeInput
}
Response
{
  "data": {
    "updateDataVolume": {
      "dvId": "a96cc3db403a7567",
      "name": "JWST - Public Data",
      "path": "jwst_jwst01_data",
      "url": "nfs://server1.volumes.datalabs.esa.int/jwst_jwst01_data",
      "dataCentreIds": ["*"],
      "clusterIds": ["c-m-m28vdqgf"],
      "automount": true
    }
  }
}
Mutations

updateRole

Description

Update a role

  1. Permissions required: "user-management/manage" on target "role"
  2. UI contexts: 2.1. When user clicks the "Edit role" button on the "Role Properties" modal window.
  3. Data created/updated: the role record specified has been update from EDL database
  4. Input variables: id (of the role to be updated), cosmosLdapGroup (to be updated for the role)
Response

Returns a Role!

Arguments
Name Description
roleID - ID! Role unique identifier. Example: team/test
input - UpdateRoleInput! Elements to update the role: cosmosLdapGroup

Example

Query
mutation UpdateRole(
  $roleID: ID!,
  $input: UpdateRoleInput!
) {
  updateRole(
    roleID: $roleID,
    input: $input
  ) {
    id
    description
    target
    permissions {
      id
      description
      target
    }
    cosmosLdapGroup
  }
}
Variables
{
  "roleID": "workspace-services/team-member/TestLuisan",
  "input": UpdateRoleInput
}
Response
{
  "data": {
    "updateRole": {
      "id": "resource-management/datalab",
      "description": "Datalab role on the jl-pipeman target with the namespace resource-management",
      "target": "jl-pipeman",
      "permissions": [Permission],
      "cosmosLdapGroup": "XYZ Datalabs Member"
    }
  }
}
Mutations

updateSystemPipeline

Description

Update a system pipeline in the pipeline catalogue. This includes updates that cause a version update and without version update (e.g. add label)

  1. Permissions required: pipeline-services/update on target system-pipeline
  2. UI contexts: 2.1. When user clicks the "Update Pipeline Step" button on the "Pipeline Step details" modal window.
  3. Data created/updated: see listed field(s) of the response data type(s).
  4. Input variables: see list of arguments below for details.
  5. Response explanation: query response is successful if the fields requested are returned with values. Unsuccessful response contains null in data block and an additional "errors" block listing the errors that occurred
Response

Returns a SystemPipeline!

Arguments
Name Description
input - UpdateSystemPipelineInput Identifier of the system pipeline or step to be updated and pipeline or step name, description, keywords, roles etc

Example

Query
mutation UpdateSystemPipeline($input: UpdateSystemPipelineInput) {
  updateSystemPipeline(input: $input) {
    id
    name
    description
    version {
      latestVersion
      defaultVersion
      codeVersion {
        ...SystemPipelineCodeFragment
      }
    }
    owner {
      username
      displayName
      roles {
        ...RoleFragment
      }
    }
    labels
    createdDate
    lastModified
    clusterIds
    defaultExecutionEngine {
      name
      displayName
      status
    }
    allowedRoles
  }
}
Variables
{"input": UpdateSystemPipelineInput}
Response
{
  "data": {
    "updateSystemPipeline": {
      "id": "94ce5c60-7c45-44d0-aa9e-430df28c87fe",
      "name": "BC_MCAM",
      "description": "This pipeline contains 2 steps: tm2raw_mcam and pds4_packager.",
      "version": SystemPipelineVersion,
      "owner": User,
      "labels": ["example-pipeline"],
      "createdDate": "2023-05-10T15:13:36.102336",
      "lastModified": "2023-05-10 15:14:23.097174",
      "clusterIds": ["c-m-m28vdqgf"],
      "defaultExecutionEngine": ExecutionEngine,
      "allowedRoles": ["pipeline-services/developer"]
    }
  }
}
Mutations

upsertAssets

Description

Insert or update assets: team (workspace) or data volume

  1. Permissions required: permission discovery-services/manage-assets
  2. UI contexts: 2.1. New data volume: Click on "Data Volumes" option in top menu, then, click on "Add from catalog", next, click on +. Fill in all the relevant fields. Click "Create Data Volume". 2.2. Updated data volume: Click on "Data Volumes" option in top menu. Click on one data volume card. Click Edit in the modal window. Change the relevant field values. Click "Update Data Volume" 2.3. New team (workspace): As operator, go to datalabs.esa.int/team-manager (or click on the user menu -> Teams). Click on the “+” button. After filling in the input variable field values click "Create Team". 2.4. Updated team (workspace): As operator, go to datalabs.esa.int/team-manager (or click on the user menu -> Teams). Open a particular team members page. Click Edit Team Metadata. Change the relevant field values. Click "Update Team"
  3. Data created/updated: see listed field(s) of the request examples.
  4. Input variables: For new team creation the minimum required set is: Workspace identifier, Title, Description. Identifier can only contain numbers, characters and dash - symbol. Description must be at least 50 characters long. For new data volume the minimum required set is: title, description
  5. Response explanation: if the response contains the assetUri and an empty messaege then the deletion was successful.
Response

Returns [ProcessingResult!]!

Arguments
Name Description
assets - [AssetInput!]! List of assets to insert or update

Example

Query
mutation UpsertAssets($assets: [AssetInput!]!) {
  upsertAssets(assets: $assets) {
    assetUri
    messages
  }
}
Variables
{"assets": [AssetInput]}
Response
{"data": {"upsertAssets": [{"assetUri": "NbDWWLKvwyy8", "messages": []}]}}
Mutations

upsertBot

Description

Create or update a bot

  1. Permissions required: user-management/create(bot)
  2. UI contexts: not implemented in UI
  3. Data created/updated:bot record created or updated. see listed field(s) of the response data type(s).
  4. Input variables: see argument description below.
  5. Response explanation: see the type Bot for explanation.
Response

Returns a Bot

Arguments
Name Description
input - BotInput! In case of create, no input variables needed. In case of update id and (name or key) needed.

Example

Query
mutation UpsertBot($input: BotInput!) {
  upsertBot(input: $input) {
    id
    name
    key
  }
}
Variables
{"input": BotInput}
Response
{
  "data": {
    "upsertBot": {
      "id": "83bc47b09992c48d",
      "name": "testingBot",
      "key": "f2061d02bff8a5985e1864b28b74a1bc588310fb3c4d2f82ac24a272f7d7f169"
    }
  }
}
Mutations

validateBuild

Description

Validate a build of a datalab published by a developer Used in the approval screen of the datalab details view You need to be moderator or operator Inputs: the build id, datalab will be infered based on it valid boolean will be True if the build is approved or False if rejected comment is a little message from the moderator or operator to the developer test allows to no trigger the publish pipeline Outputs: the value of the BuildStatus, see the definition of BuildStatus

Response

Returns an Int!

Arguments
Name Description
build - ID!
valid - Boolean
comment - String
test - Boolean

Example

Query
mutation ValidateBuild(
  $build: ID!,
  $valid: Boolean,
  $comment: String,
  $test: Boolean
) {
  validateBuild(
    build: $build,
    valid: $valid,
    comment: $comment,
    test: $test
  )
}
Variables
{
  "build": "3d971341-136b-43e6-8298-bd8913edf77b",
  "valid": false,
  "comment": "",
  "test": true
}
Response
{"data": {"validateBuild": 987}}

Subscriptions

monitorBuildProgress

Description

Push the status change for the build, from NONE to SUBMITED to SUCCESS or FAIL Used in Datalab testing screen see the documentation for BuildProgress for details on each status. You need to be developer or internal developer to see the status of your build. This subscription is done on the DLD section on the build screen when clicking on build or rebuild button Input: build the identifier of the build which is returned by the buildDatalab mutation Output: the current status of the build

Response

Returns a BuildProgress

Arguments
Name Description
build - ID! The ID of the build process instance

Example

Query
subscription MonitorBuildProgress($build: ID!) {
  monitorBuildProgress(build: $build)
}
Variables
{"build": "3d971341-136b-43e6-8298-bd8913edf77b"}
Response
{"data": {"monitorBuildProgress": "NONE"}}
Subscriptions

monitorLog

Description

Push the log of a build to the UI Used in Datalab testing screen You need to be developer or internal developer to see the logs of the build Input: the build id called pipelineRef mandatory. the last log id, in order to restart from a previous log subscription. Output: the log lines

Response

Returns an DLDPipelineLog

Arguments
Name Description
pipelineRef - String!
lastId - String
clusterId - ID

Example

Query
subscription MonitorLog(
  $pipelineRef: String!,
  $lastId: String,
  $clusterId: ID
) {
  monitorLog(
    pipelineRef: $pipelineRef,
    lastId: $lastId,
    clusterId: $clusterId
  ) {
    id
    log
    status
    task
    tasks
    pod
  }
}
Variables
{
  "pipelineRef": "sciapps-build-datalab-4rnpm",
  "lastId": null,
  "clusterId": "95jsh18jec3vghow"
}
Response
{
  "data": {
    "monitorLog": {
      "id": "1716378716260-0",
      "log": "Not a git repository, skipped\nCleaning directory\n  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current\n                                 Dload  Upload   Total   Spent    Left  Speed\n\r  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0\r100   98k  100   98k    0     0   938k      0 --:--:-- --:--:-- --:--:--  961k\nArchive:  /workspace/output/deaef60e-bde6-4ca8-b284-79b03db417b2/archive.zip\n extracting: /workspace/output/deaef60e-bde6-4ca8-b284-79b03db417b2/file.txt  \n",
      "status": "Succeeded",
      "task": "sciapps-build-datalab-4rnpm-fetch-sources-pod",
      "tasks": [null],
      "pod": "sciapps-build-datalab-4rnpm-fetch-sources-pod-hd1s2"
    }
  }
}
Subscriptions

monitorMessages

Description

Push an event to the UI when the datalab or the build change in order to refresh the UI Used in main DLD screen You need to be connected to the application to receive the events. Nevertheless you won't receive the events as it is for builds. Input: dedicated channel for the communication based on the user name Output: the event object for more information see the definition of the event

Response

Returns a MonitoringEvent

Arguments
Name Description
channel - String!

Example

Query
subscription MonitorMessages($channel: String!) {
  monitorMessages(channel: $channel) {
    type
    body
  }
}
Variables
{"channel": "some-redis-channel-name"}
Response
{
  "data": {
    "monitorMessages": {"type": "Build", "body": "Build started successfully"}
  }
}
Subscriptions

monitorPipelineRun

Description

Register for pipeline run updates

Response

Returns a String

Arguments
Name Description
id - ID Unique identifier of the pipeline run about which the updates are needed

Example

Query
subscription MonitorPipelineRun($id: ID) {
  monitorPipelineRun(id: $id)
}
Variables
{"id": "d94cafae-e907-47fd-9d41-23ef1798948c"}
Response
{
  "data": {
    "monitorPipelineRun": "some-value"
  }
}
Subscriptions

userEvent

Description

Emit event as JSON structure with the user event data

Response

Returns a String

Example

Query
subscription UserEvent {
  userEvent
}
Response
{"data": {"userEvent": "some-value"}}

Types

Announcement

Description

User interface top part announcement configuration information

Fields
Field Name Description
announcement - String Announcement text for the banner shown in the top part of the ESA Datalabs user interface for all users. Empty if there's no announcement to show. Allows insertion of HTML tags to format the text.
textColorCode - String Color of the announcment text characters. Hexadecimal triplet in format #RRGGBB.
backgroundColorCode - String Color of the announcment text background. Hexadecimal triplet in format #RRGGBB.
createdTime - DateTime Last time the announcmenet record was updated. Taken from current system time of UTC timezone (generated by system on updates).
Example
{
  "announcement": "<br><center>Banner text update test 1</center></br>",
  "textColorCode": "#00008B",
  "backgroundColorCode": "#50EBEC",
  "createdTime": "2024-04-24T13:57:35.621599"
}
Types

AssetInput

Description

Parameters for inserting or updating an asset. An asset may be a data volume catalog item, a team workspace.

Fields
Input Field Description
data - String! JSON encoded asset data.
vocabulary - Vocabulary! Data is expressed in this controlled vocabulary type. Allowed values: INTERNAL, SDO, DCAT)
type - String The type of the asset (optional). Allowed values: team (for team workspace), dataset (for data volume)
Example
{
  "data": "{\"title\":\"NR Team for ESA Datalabs 2\",\"alternateName\":\"NRTeamforEDL2\",\"type\":\"https://data.esa.int/esado/Team\",\"description\":\"New team created for testing purposes only and nothing more! test 2\",\"identifier\":[\"https://data.esa.int/asset/vefayPcEJMHJ\"]}",
  "vocabulary": "INTERNAL",
  "type": "team"
}
Types

AuthenticationState

Description

Representation of how the server currently recognized the client, and possible methods for authentication

  1. Access roles: none required
  2. UI contexts: 2.1. When user opens the EDL login page.
  3. Data returned: see listed fields below.
  4. Filter: none
  5. Input arguments: none
Fields
Field Name Description
backends - String! A list of available authentication backends, as a space separated string. CAS = Cosmos Central Authentication Service. Always included.
username - String Identification of the currently authenticated user. Always included. May be null.
token - String Access token for programmatic access.
timestamp - Int Token's issue time (POSIX time).
user - User Detailed user information. Always included. May be null.
Example
{
  "backends": "CAS",
  "username": "etestuser",
  "token": "eyJ1c2VyX2lkIjogInVzZXIifQ.ZkYBTw.GRLKzLezKcpdH7MJueKnUIdBl8M",
  "timestamp": 1715616642,
  "user": User
}
Types

Boolean

Description

The Boolean scalar type represents true or false.

Types

Bot

Description

System-level user for automated tasks

Fields
Field Name Description
id - ID! Unique identifier of a bot. Example: 83bc47b09992c48d
name - String! Name of the bot. Example: testingBot
key - String Key of the bot. Example: f2061d02bff8a5985e1864b28b74a1bc588310fb3c4d2f82ac24a272f7d7f169
Example
{
  "id": "83bc47b09992c48d",
  "name": "testingBot",
  "key": "f2061d02bff8a5985e1864b28b74a1bc588310fb3c4d2f82ac24a272f7d7f169"
}
Types

BotInput

Description

Data input structure for creating or updating a bot

Fields
Input Field Description
id - ID Unique identifier of a bot. Example: 83bc47b09992c48d
name - String Name of the bot. Example: testingBot
key - String Key of the bot. Example: f2061d02bff8a5985e1864b28b74a1bc588310fb3c4d2f82ac24a272f7d7f169
Example
{
  "id": "83bc47b09992c48d",
  "name": "testingBot",
  "key": "f2061d02bff8a5985e1864b28b74a1bc588310fb3c4d2f82ac24a272f7d7f169"
}
Types

BuildBookmarks

Description

A bookmarked datalab

Fields
Field Name Description
datalab - ID!
Example
{"datalab": "cdce7d27-fc5e-44da-b326-875624b6cbac"}
Types

BuildLog

Fields
Field Name Description
logs - [DLDPipelineLog] The content of the logs
params - LogParams The parameters given to retrieve the logs
Example
{
  "logs": [DLDPipelineLog],
  "params": LogParams
}
Types

BuildProgress

Values
Enum Value Description

NONE

 Never launched a build

SUBMITED

 Build is in progress

BUILD_SUCCESS

 Build is completed successfully

BUILD_FAIL

 Build is completed but failed
Example
"NONE"
Types

BuildStatus

Description

Hold the list of status for the build

Values
Enum Value Description

DRAFT

UNDER_MODERATION

VALIDATED

REJECTED

PUBLISHED

ARCHIVED
Example
"DRAFT"
Types

Cluster

Description

Cluster for running datalabs or pipelines

Fields
Field Name Description
id - ID! Unique identifier for the cluster
displayName - String! Human-readable name of the cluster
displayLabel - String! Short form label of the cluster
default - Boolean! Indicates if this is the default cluster within the data centre
dataCentreId - String! Unique identifier for the data centre where cluster is located in
Example
{
  "id": "c-m-m28vdqgf",
  "displayName": "ESA cluster",
  "displayLabel": "ESA",
  "default": true,
  "dataCentreId": "esadc01"
}
Types

Code

Description

Source code for pipeline or pipeline step

Fields
Field Name Description
filename - String! Source code file name for pipeline or pipeline step
text - String! Source code contents for pipeline or pipeline step
Example
{
  "filename": "manifest.json",
  "text": "{\n  \"README\": \"Do not manually edit this file! Properties 'id' and 'version' are from Catalogue\",\n  \"entrypointFilename\": \"BC_MCAM.pipeline.cwl\",\n  \"version\": \"0.0.2\",\n  \"dependencies\": {\n    \"dependencies/tm2raw_mcam/tm2raw_mcam.step.cwl\": {\n      \"version\": \"0.0.2\",\n      \"id\": \"20f683bb-407b-4a8b-ab5d-72f25df44ce3\"\n    },\n    \"dependencies/pds4_packager/pds4_packager.step.cwl\": {\n      \"version\": \"0.0.2\",\n      \"id\": \"10a519e1-b4a8-4825-9fb5-800debbb1e42\"\n    }\n  },\n  \"id\": \"47acb0fd-f8ee-446f-b345-4589d404c8ad\"\n}"
}
Types

CodeInput

Description

Source code for pipeline or pipeline step

Fields
Input Field Description
filename - String! Source code file name for pipeline or pipeline step
text - String! Source code contents for pipeline or pipeline step
Example
{
  "filename": "manifest.json",
  "text": "{\n  \"README\": \"Do not manually edit this file! Properties 'id' and 'version' are from Catalogue\",\n  \"entrypointFilename\": \"BC_MCAM.pipeline.cwl\",\n  \"version\": \"0.0.2\",\n  \"dependencies\": {\n    \"dependencies/tm2raw_mcam/tm2raw_mcam.step.cwl\": {\n      \"version\": \"0.0.2\",\n      \"id\": \"20f683bb-407b-4a8b-ab5d-72f25df44ce3\"\n    },\n    \"dependencies/pds4_packager/pds4_packager.step.cwl\": {\n      \"version\": \"0.0.2\",\n      \"id\": \"10a519e1-b4a8-4825-9fb5-800debbb1e42\"\n    }\n  },\n  \"id\": \"47acb0fd-f8ee-446f-b345-4589d404c8ad\"\n}"
}
Types

CreateDatalabInput

Description

Instantiation options for a new datalab

Fields
Input Field Description
dlpId - ID!
idAsName - Boolean
name - String
categories - Int
config - String
volumes - [ID!]
image - String
version - String
isDev - Boolean
build - ID
launchRef - String
resources - RuntimeResourcesInput
clusterId - ID Unique identifier for the cluster where the datalab instance will be created
Example
{
  "dlpId": "jl-pipeman",
  "idAsName": false,
  "name": "jl-pipeman",
  "categories": 1,
  "config": null,
  "volumes": [],
  "image": "jl-pipeman",
  "version": "0.0.1",
  "isDev": false,
  "build": "3d971341-136b-43e6-8298-bd8913edf77b",
  "launchRef": null,
  "resources": RuntimeResourcesInput,
  "clusterId": "c-m-m28vdqgf"
}
Types

CreatePermissionInput

Description

Input for the creation of a new Permission

Fields
Input Field Description
id - ID! Unique identifier of a permission.Example: workspace-services/manage
target - String! Target object name. Example: dez6
description - String Description of the permission. Example: on the target with the namespace
roles - [ID!]! List of roles by id. Example of role id: workspace-services/team-manager/dez16
Example
{
  "id": "workspace-services/manage",
  "target": "dez6",
  "description": "Testing the permission creation for ICD documentation",
  "roles": ["workspace-services/team-manager/dez16"]
}
Types

CreateRoleInput

Description

Input for the creation of a new Role

Fields
Input Field Description
id - ID! Unique identifier of the role to be created. Naming pattern: Role Namespace/Role Identifier
target - String The target object for which the role groups permissions that allow a user to perform an action on the target.
members - [ID!]! List of user ID-s who will be added to he role. By default it contains the user ID of the role creator.
description - String Description of the role
cosmosLdapGroup - String Cosmos LDAP group to synchronize members from
Example
{
  "id": "user-management/view",
  "target": "role",
  "members": ["etestuser"],
  "description": "Testing role creation",
  "cosmosLdapGroup": "XYZ Datalabs Member"
}
Types

DLDPipelineLog

Fields
Field Name Description
id - String Id of the tasks
log - String Log lines of the current tasks
status - String status of the current task
task - String Current task
tasks - [String] list of tasks
pod - String the pod id
Example
{
  "id": "1716378716260-0",
  "log": "Not a git repository, skipped\nCleaning directory\n  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current\n                                 Dload  Upload   Total   Spent    Left  Speed\n\r  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0\r100   98k  100   98k    0     0   938k      0 --:--:-- --:--:-- --:--:--  961k\nArchive:  /workspace/output/deaef60e-bde6-4ca8-b284-79b03db417b2/archive.zip\n extracting: /workspace/output/deaef60e-bde6-4ca8-b284-79b03db417b2/file.txt  \n",
  "status": "Succeeded",
  "task": "sciapps-build-datalab-4rnpm-fetch-sources-pod",
  "tasks": [null],
  "pod": "sciapps-build-datalab-4rnpm-fetch-sources-pod-hd1s2"
}
Types

DataCentre

Description

Data centre for hosting the cluster(s) that enable the running of datalabs or pipelines

Fields
Field Name Description
id - ID! Unique identifier for the data centre
displayName - String! Human-readable name of the data centre
clusters - [Cluster]! List of clusters within this data centre
Example
{
  "id": "esadc01",
  "displayName": "ESA",
  "clusters": [Cluster]
}
Types

DataVolume

Description

Description of a data volume

Fields
Field Name Description
dvId - ID! Unique identifier of the data volume. Example value: a96cc3db403a7567
name - String! data volume user-defined name. Example value: JWST - Public Data
path - String! Folder name inside the datalab. Example value: jwst_jwst01_data
url - String! Data source URL. Example value: nfs://server1.volumes.datalabs.esa.int/jwst_jwst01_data
dataCentreIds - [ID!]! An array of data centre ids where data volume is available
clusterIds - [ID!]! An array of cluster ids where data volume is available
automount - Boolean Automount in all datalabs on volume creation and when a new datalab is launched. true = volume is automounted in a datalab. false = volume is not automounted in a datalab.
Example
{
  "dvId": "a96cc3db403a7567",
  "name": "JWST - Public Data",
  "path": "jwst_jwst01_data",
  "url": "nfs://server1.volumes.datalabs.esa.int/jwst_jwst01_data",
  "dataCentreIds": ["*"],
  "clusterIds": ["c-m-m28vdqgf"],
  "automount": true
}
Types

DataVolumeInput

Description

Metadata of a data volume

Fields
Input Field Description
url - String! Data source URL
path - String! Folder name inside the datalab
name - String Custom name
dataCentreIds - [ID!]! An array of data centre ids where data volume is available
clusterIds - [ID!]! An array of cluster ids where data volume is available
automount - Boolean Automount in all datalabs on volume creation and when a new datalab is launched. true = volume is automounted in a datalab. false = volume is not automounted in a datalab.
Example
{
  "url": "nfs://server1.volumes.datalabs.esa.int/jwst_jwst01_data",
  "path": "jwst_jwst01_data",
  "name": "JWST - Public Data",
  "dataCentreIds": ["*"],
  "clusterIds": ["c-m-m28vdqgf"],
  "automount": true
}
Types

Datalab

Fields
Field Name Description
id - ID!
dlp - DatalabPackage!
nodeUrl - String
containerId - String
name - String
creation_time - DateTime
secret - String
categories - Int
state - String
details - String
config - String
resources - [Resource!]!
launchRef - String
clusterId - ID!
last_access_time - DateTime Last access datetime of a user’s datalab. When a datalab has not been accessed, then null is returned.
Example
{
  "id": "0cc7edf6-736b-42f6-891f-f395cc7896bc",
  "dlp": DatalabPackage,
  "nodeUrl": "",
  "containerId": "",
  "name": "jl-pipeman",
  "creation_time": "2025-01-14T12:15:30.062338",
  "secret": "cb3517e95b5cbacf",
  "categories": 1,
  "state": "running",
  "details": "",
  "config": null,
  "resources": [Resource],
  "launchRef": null,
  "clusterId": "c-m-m28vdqgf",
  "last_access_time": "2025-01-14T16:18:22.071397"
}
Types

DatalabBuild

Description

Represent a version of the datalab that was built

Fields
Field Name Description
id - ID! Identifier from the database
datalabId - ID! The datalab it belongs to
version - String! The build version
status - BuildStatus The status of the build
runtimeConfiguration - RuntimeConfiguration information regarding the resources needed to run the build
created_at - String!
buildRef - String the reference to the pipeline that built the current build
scanRef - String the reference to the pipeline that scanned the current build
logs - String list of events associated to this build
progress - String build progress is the status of the last build (BUILD_SUCCESS, BUILD_FAIL)
Example
{
  "id": "3d971341-136b-43e6-8298-bd8913edf77b",
  "datalabId": "b27cda74-2db7-46ec-b287-a6353a47e74a",
  "version": "0.0.1-0",
  "status": "PUBLISHED",
  "runtimeConfiguration": RuntimeConfiguration,
  "created_at": "1715696521.537044",
  "buildRef": "sciapps-build-datalab-4ltcw",
  "scanRef": null,
  "logs": "Build started (sciapps-build-datalab-4ltcw)#!1715696521.539653!#Build ended with status BUILD_SUCCESS#!1715696617.206669!#Build marked as UNDER_MODERATION#!1715697174.958686!#Build marked as PUBLISHED#!1715697826.405907!#Approved#!1715697826.407465!#Datalab build published in the public catalog#!1715697848.135899!#Build archived#!1715773558.998771!#Build unarchived#!1715783367.895708!#Datalab build published in the public catalog#!1715783388.069154!#",
  "progress": "BUILD_SUCCESS"
}
Types

DatalabClass

Description

This type represents a Datalab not yet completed and published. It has more information than the datalab package that can be run.

Fields
Field Name Description
id - ID! Database id
owner - User! The creator of the Datalab class
is_public - Boolean! Indicate if the user published it via the moderation flow
created_at - String Timestamp for traceability
modified_at - String
repository - String The Git repository of the source code
branch - String The branch inside the git repository
artefact - String The link to the source code if not a git repository
status - DatalabStatus The datalab status (PUBLISHED,DRAFT...)
name - String Human Readable name
description - String Description for the metadata
icon - String Deprecated: the icon is now using the icon API to retrieve it
runtimeConfiguration - RuntimeConfiguration Technical metadata DEPRECATED use the build runtime metadata configuration
metadata - [MetadataEntry!] Extra / Discovery metadata, check MetadataEntry for details
nstars - Int! Number of time the datalab was bookmarked
version - String Version of the datalab
Example
{
  "id": "deaef60e-bde6-4ca8-b284-79b03db417b2",
  "owner": User,
  "is_public": false,
  "created_at": "1715163378.021328",
  "modified_at": "1715163471.601883",
  "repository": null,
  "branch": null,
  "artefact": null,
  "status": "DRAFT",
  "name": "testing-lab",
  "description": "A test",
  "icon": null,
  "runtimeConfiguration": RuntimeConfiguration,
  "metadata": [MetadataEntry],
  "nstars": 0,
  "version": "0.0.1"
}
Types

DatalabLog

Fields
Field Name Description
logs - String!
params - LogParams
Example
{"logs": "Running docker lint...", "params": LogParams}
Types

DatalabMetadata

Fields
Field Name Description
name - String
description - String
icon - String
runtimeConfiguration - RuntimeConfiguration Technical metadata
metadata - [MetadataEntry!] Extra / Discovery metadata
Possible Types
DatalabMetadata Types

DatalabClass
Example
{
  "name": "SAOImageDS9",
  "description": "SAOImageDS9 is interactive graphical viewer for astronomical images and catalogues",
  "icon": "https://raw.githubusercontent.com/kalaschsoyuz/kalaschsoyuz.github.io/main/ds9-logo.svg",
  "runtimeConfiguration": RuntimeConfiguration,
  "metadata": [MetadataEntry]
}
Types

DatalabPackage

Description

Describes a runnable datalab, datalab that was built and published to the Helm repository

Fields
Field Name Description
id - ID! The datalab ID in the database
name - String! The readable name of the datalab
image - String The docker image used, this field is optional and almost never returned
description - String Description coming from the Helm chart
config - String Configuration used to create the Datalab
version - String Latest version of the datalab
Example
{
  "id": "jl-pipeman",
  "name": "jl-pipeman",
  "image": "jl-pipeman",
  "description": "Jupyter lab with pipeman python library.",
  "config": null,
  "version": "0.0.4"
}
Types

DatalabSecretCheck

Fields
Field Name Description
username - String!
valid - Boolean!
Example
{"username": "etestuser", "valid": true}
Types

DatalabStatus

Values
Enum Value Description

NEW

 Just created

DRAFT

 Has sources

REMOVED

 Was deleted
Example
"NEW"
Types

DateTime

Example
"2007-12-03T10:15:30Z"
Types

DeletePipelineRunInput

Description

The pipeline run to be deleted

Fields
Input Field Description
id - [ID!] The unique identifier(s) of pipeline run(s) to be deleted
Example
{"id": ["d94cafae-e907-47fd-9d41-23ef1798948c"]}
Types

DeleteSystemPipelineInput

Description

The system pipeline to be deleted

Fields
Input Field Description
id - ID! The unique identifier of the system pipeline to be deleted
force - Boolean The parameter to force the deletion regardless of warnings. True = force delete even if the step/pipeline is being used by another step/pipeline. False = do not delete step/pipeline if it is being used by another step/pipeline.
Example
{"id": "94ce5c60-7c45-44d0-aa9e-430df28c87fe", "force": false}
Types

DeploymentError

Fields
Field Name Description
hasError - Boolean! If an error occurs while deploying a datalab instance
message - String Comment describing the error
inProgress - Boolean! If deployment status is in progress
Example
{
  "hasError": true,
  "message": "pods \"datalab-ff02932e67a79164-598bc9b866-fpsg4\" is forbidden: exceeded quota: user-quota, requested: limits.cpu=88, used: limits.cpu=0, limited: limits.cpu=16:replicas: 0/1",
  "inProgress": true
}
Types

DockerImage

Description

Metadata for Docker Image that contains processing logic of a pipeline step

Fields
Field Name Description
name - String Docker image name
versions - [String] List of pipeline step docker image versions available for selection
Example
{"name": "step/example_base", "versions": ["v1"]}
Types

ExecutionEngine

Description

Pipeline launching execution engine metadata

Fields
Field Name Description
name - String! Pipeline launching execution engine backend name
displayName - String! Pipeline launching execution engine name in user interface, e.g. Calrissian
status - String Pipeline execution backend status. UP = running and available, DOWN = not available
Example
{"name": "CALRISSIAN", "displayName": "Calrissian", "status": "UP"}
Types

ExecutionEngineInput

Description

Input for adding the pipeline execution engine

Fields
Input Field Description
name - String! Pipeline launching execution engine backend name
displayName - String! Pipeline launching execution engine name in user interface, e.g. Calrissian
Example
{"name": "CALRISSIAN", "displayName": "Calrissian"}
Types

HelpPageIds

Description

Unique identifiers of the Help pages

Fields
Field Name Description
sectionIds - [String] ids for specific help page sections
Example
{"sectionIds": ["src-296321073_PipelineEditorGUI-CommandCommand"]}
Types

ID

Description

The ID scalar type represents a unique identifier, often used to refetch an object or as key for a cache. The ID type appears in a JSON response as a String; however, it is not intended to be human-readable. When expected as an input type, any string (such as "4") or integer (such as 4) input value will be accepted as an ID.

Example
"95jsh18jec3vghow"
Types

Input

Description

Pipeline input parameters that were used to launch the Pipeline

Fields
Field Name Description
parameters - [Parameter]! List of parameters used when the pipeline was launched (mandatory)
Example
{"parameters": [Parameter]}
Types

Int

Description

The Int scalar type represents non-fractional signed whole numeric values. Int can represent values between -(2^31) and 2^31 - 1.

Example
123
Types

License

Description

Licence for a datalab publication

Fields
Field Name Description
name - String! To be displayed in the UI
id - String! To be linked to the datalab
link - String! To be open to read the content of the licence
category - String To be grouped in different category
Example
{
  "name": "Apache License 2.0",
  "id": "Apache-2.0",
  "link": "https://www.apache.org/licenses/LICENSE-2.0",
  "category": "Popular Licenses"
}
Types

Log

Description

Generic log entry data type for pipeline and pipeline step logs

Fields
Field Name Description
text - String Log entry text
time - String Log entry recording date and time stamp
Example
{"text": "code.sh: line 4: first: command not found\n", "time": null}
Types

LogLevel

Description

Logging levels are defined in https://docs.python.org/3/library/logging.html#logging-levels

Values
Enum Value Description

NOTSET

DEBUG

INFO

WARNING

ERROR

CRITICAL
Example
"NOTSET"
Types

LogParams

Fields
Field Name Description
pod - String
pipeline - String
namespace - String
cluster_id - String
Example
{
  "pod": "datalab-6d282122f0a6719f-868f5cddfd-c92p7",
  "pipeline": "sciapps-publish-datalab-l8f2f",
  "namespace": "nsdatalab-56061",
  "cluster_id": "local"
}
Types

MetadataEntry

Description

The metadata storage is used to retrieve and store the metadata It also describes the metadata for an easy rendering in the UI

Fields
Field Name Description
name - String! Name of the metadata
value - String Value of the metadata
definition - MetadataEntryDefinition Criteria of the metadata
Example
{
  "name": "version",
  "value": "1.0.0",
  "definition": MetadataEntryDefinition
}
Types

MetadataEntryDefinition

Description

Holds the metadata characteristics

Fields
Field Name Description
description - String! Description of the metadata shown in the UI
type - String! Type drives the input field
visibility - String! Drives if according to the current user it should be displayed or not
owner - String! Who should fill the input field
required - Boolean Needed to complete the datalab creation or update
sensitive - Boolean Allows to protect the data like passwords or tokens
recommended - Boolean Additional category right after the required field
pattern - String Pattern to apply for field validation
errorMessage - String Error to display when validation fails
Example
{
  "description": "Version information (major.minor.patch all intergers ie: 1.2.3)",
  "type": "x.y.z",
  "visibility": "A",
  "owner": "D",
  "required": true,
  "sensitive": null,
  "recommended": null,
  "pattern": "^\\d+\\.\\d+\\.\\d+$",
  "errorMessage": "Version must be of the form major_version.minor_version.patch_version and all versions are integer."
}
Types

MetadataEntryInput

Description

Simple key-value input used to update the datalab metadata

Fields
Input Field Description
name - String!
value - String
Example
{"name": "version", "value": "1.0.0"}
Types

MonitoringEvent

Fields
Field Name Description
type - String! The event type (build_approved)
body - String! The build id associated with the event
Example
{"type": "Build", "body": "Build started successfully"}
Types

Node

Fields
Field Name Description
id - ID!
Possible Types
Node Types

DatalabBuild
Example
{"id": "3d971341-136b-43e6-8298-bd8913edf77b"}
Types

Notification

Description

Optional notification e-mail that can be configured during pipeline launch definition and will be sent during or after pipeline launch

Fields
Field Name Description
email - String E-mail address whereto the pipeline notification will be sent
trigger - String The triggering event that causes the notification e-mail to be sent: 'pipeline fails' or 'pipeline completes' or 'pipeline exceeds time limit of'
triggerData - TriggerData Additional trigger data, specific to trigger, e.g. run time limit before notification gets sent
Example
{
  "email": "etestuser@email.com",
  "trigger": "PIPELINE_COMPLETED",
  "triggerData": TriggerData
}
Types

NotificationInput

Description

Optional notification e-mail that can be configured during pipeline launch definition and will be sent during or after pipeline launch

Fields
Input Field Description
email - String! E-mail address whereto the pipeline notification will be sent
trigger - String! The triggering event that causes the notification e-mail to be sent: 'pipeline fails' or 'pipeline completes' or 'pipeline exceeds time limit of'
triggerData - TriggerDataInput Additional trigger data, specific to trigger, e.g. run time limit before notification gets sent
Example
{
  "email": "etestuser@email.com",
  "trigger": "PIPELINE_COMPLETED",
  "triggerData": TriggerDataInput
}
Types

ObjectID

Description

Data type to hold the object unique identifier of a resource that the user may be authorized to use if assigned a specific role.

Fields
Field Name Description
objectID - [ID!] Unique identifier of the object as a string. Example: 1f16e0675d8b77f8
Example
{"objectID": ["3d4683c4-699f-4a1a-b317-8c4b3dce23bf"]}
Types

Output

Description

Pipeline run output path, where the results go

Fields
Field Name Description
outputPath - String! Pipeline run output path, where the results go (mandatory)
Example
{"outputPath": "my_workspace/output/"}
Types

Pagination

Description

Pipeline run results pagination data for the Pipeline dashboard page of the current user

Fields
Field Name Description
totalCount - Int The total number of results
pageCount - Int The number of pages
Example
{"totalCount": 4, "pageCount": 1}
Types

Parameter

Description

Parameter for that can be used to as input when a pipeline is launched

Fields
Field Name Description
inputId - String! Unique ID of an input parameter that was used to launch a pipeline (mandatory)
value - String! Value of a pipeline parameter used during launch (mandatory)
className - String! Parameter type in CWL, such as Int, File (mandatory)
Example
{"inputId": "data", "value": "my_workspace/rids.txt", "className": "File"}
Types

ParameterInput

Description

Parameter for that can be used to as input when a pipeline is launched

Fields
Input Field Description
inputId - String! Unique ID of an input parameter that was used to launch a pipeline (mandatory)
value - String! Value of a pipeline parameter used during launch (mandatory)
className - String! Parameter type in CWL, such as Int, File (mandatory)
Example
{"inputId": "data", "value": "my_workspace/rids.txt", "className": "File"}
Types

Permission

Description

A user right to perform certain action on a certain data object type

Fields
Field Name Description
id - ID! Unique identifier of a permission. Naming pattern: EDL RBAC Namespace/user action
description - String Explanation using the pattern: on the target with the namespace
target - String The target object for which the permission grants the user to perform the action.
Example
{
  "id": "workspace-services/manage",
  "description": "Testing the permission creation for ICD documentation",
  "target": "dez6"
}
Types

Pipeline

Types
Union Types

UserPipeline

SystemPipeline
Example
UserPipeline
Types

PipelineLog

Description

Pipeline execution log

Fields
Field Name Description
logs - [Log] Pipeline main log. This log excludes step logs
Example
{"logs": [Log]}
Types

PipelineRun

Description

Metadata of one run instance of a pipeline

Fields
Field Name Description
id - ID! Unique identifier of a pipeline run (mandatory)
owner - User! Pipeline run initiating user (mandatory)
pipeline - Pipeline! Metadata of the pipeline which ws run, e.g. pipeline id, pipeline description, version etc
identifier - String! The name of the Pipeline run, defaults to Pipeline name (mandatory)
status - RunStatus! Pipeline run status: SUBMITTED, SCHEDULED, RUNNING, FAILED, COMPLETED, KILLED (mandatory)
totalStepCount - Int! Number of Pipeline Steps to run through. May not be known in advance in case of scattered Pipeline (mandatory)
steps - [StepRun] A list of Pipeline step runs with their statuses
startDate - DateTime Pipeline execution start date
endDate - DateTime Pipeline execution end date
input - Input! Pipeline input parameters (mandatory)
output - Output! Pipeline output (mandatory)
schedule - Schedule Schedule that trigger automatically new pipeline runs
notifications - [Notification] List of notifications related to pipeline run
defaultImage - String The default image for the pipeline, if pipeline step is missing Docker requirement
executionEngine - ExecutionEngine Pipeline execution backend that runs the Pipeline. E.g. Calrissian
labels - [String] Keywords that tag this run and can be used for searching, filtering it
log - PipelineLog Pipeline run events log
externalTrigger - Boolean Externally triggered pipeline (True) or not (False)
pipelineType - PipelineType! The Pipeline type: can be User Pipeline (USER), System Pipeline (SYSTEM), Test Pipeline (TEST). (mandatory)
Example
{
  "id": "d94cafae-e907-47fd-9d41-23ef1798948c",
  "owner": User,
  "pipeline": UserPipeline,
  "identifier": "pipeline-run-test-2",
  "status": "COMPLETED",
  "totalStepCount": 0,
  "steps": [StepRun],
  "startDate": "2023-06-12T08:28:49.146531",
  "endDate": "2023-06-12T08:29:40.494027",
  "input": Input,
  "output": Output,
  "schedule": Schedule,
  "notifications": [Notification],
  "defaultImage": "",
  "executionEngine": ExecutionEngine,
  "labels": ["example-run"],
  "log": PipelineLog,
  "externalTrigger": true,
  "pipelineType": "USER"
}
Types

PipelineRunInput

Description

Input data that defines the pipeline and the way it will be run

Fields
Input Field Description
clusterId - ID! Unique identifier of a user cluster in which pipeline runs
identifier - String! 'Identifier' of the pipeline run
inputParameters - [ParameterInput]! List of parameters with their values to be used as input for pipeline run
outputPath - String! The output directory where the pipeline run will save its results
schedule - ScheduleInput A schedule that can be used to automatically generate the pipeline run(s) in the future
notifications - [NotificationInput] List of e-mail notifications that can be generated in relation to the pipeline run
defaultImage - String The default image for the pipeline, if all pipeline step is missing Docker image requirement
executionEngine - String! Pipeline launching execution engine to be used during the run
labels - [String] List of pipeline labels attached when pipeline version was published to the catalogue
Example
{
  "clusterId": "c-m-m28vdqgf",
  "identifier": "pipeline-run-test-2",
  "inputParameters": [ParameterInput],
  "outputPath": "my_workspace/output/",
  "schedule": ScheduleInput,
  "notifications": [NotificationInput],
  "defaultImage": "",
  "executionEngine": "CALRISSIAN",
  "labels": ["example-run"]
}
Types

PipelineRunResult

Description

Pipeline runs list with run metadata and pagination statistics

Fields
Field Name Description
edges - [PipelineRun]! List of pipeline runs (mandatory)
pageInfo - Pagination How many runs in total there are for the current user and on how many pages they should be shown on the dashboard
Example
{
  "edges": [PipelineRun],
  "pageInfo": Pagination
}
Types

PipelineType

Description

Type of pipeline expressing the ownership of the pipeline

Values
Enum Value Description

USER

 Custom pipeline created by and used only by one user

SYSTEM

 Pipeline has been published into system pipelines catalogue and shared with all users that have the respective access role granted to them

TEST

 A pipeline that is run during the testing phase of the development of the pipeline inside the Pipeline Editor
Example
"USER"
Types

ProcessingResult

Description

Asset insert, update, delete action results. An asset may be a data volume catalog item, a team workspace.

Fields
Field Name Description
assetUri - ID The URI of the asset, if it was accepted
messages - [String!]! Error and warning messages that resulted from the processing of the asset
Example
{"assetUri": "NbDWWLKvwyy8", "messages": []}
Types

Quota

Description

The resources used and available for a user namespace

Fields
Field Name Description
cpuLimit - String! CPU limit in Kubernetes terms
memoryLimit - String! Memory limit in Kubernetes terms
usedCpu - String! CPU used
usedMemory - String! Memory used
usedApp - String! Number of application running
appLimit - String! Maximum number of application
usedGroups - Int! Number of NFS groups used
groupsLimit - Int! Number of maximum NFS groups
Example
{
  "cpuLimit": "16",
  "memoryLimit": "64Gi",
  "usedCpu": "250m",
  "usedMemory": "384Mi",
  "usedApp": "2",
  "appLimit": "3",
  "usedGroups": 3,
  "groupsLimit": 16
}
Types

Resource

Fields
Field Name Description
id - ID!
dlId - ID!
name - String
type - Int
categories - Int
specification - String
state - ResourceState
details - String
Example
{
  "id": "e6a455ff90f27315",
  "dlId": "66f73b66fb154e02",
  "name": "jwst_jwst01_data",
  "type": 1,
  "categories": 1,
  "specification": "nfs://server1.volumes.datalabs.esa.int/jwst_jwst01_data",
  "state": "WAITING",
  "details": ""
}
Types

ResourceState

Values
Enum Value Description

DONE

ERROR

READY

WAITING
Example
"DONE"
Types

Role

Description

User access role that groups one or more permissions which are granted to the user who is assigned into this role.

Fields
Field Name Description
id - ID! Unique identifier of a role. Naming pattern: EDL RBAC Namespace/object type
description - String Role explanation using the pattern: on the target with the namespace

target - String The target object for which the role groups permissions.
permissions - [Permission] The permissions which the role grants to the user.
cosmosLdapGroup - String Cosmos LDAP group to synchronize members from
Example
{
  "id": "resource-management/datalab",
  "description": "Datalab role on the jl-pipeman target with the namespace resource-management",
  "target": "jl-pipeman",
  "permissions": [Permission],
  "cosmosLdapGroup": "XYZ Datalabs Member"
}
Types

RunOrder

Description

Sorting mode of the pipeline run cards in the user interface on page pipeline-dashboard

Values
Enum Value Description

STARTED_DESC

 Pipeline runs are sorted by newest first

STARTED_ASC

 Pipeline runs are sorted by oldest first

IDENTIFIER_ASC

 Pipeline runs are sorted alphabetically
Example
"STARTED_DESC"
Types

RunStatus

Description

Allowed statuses for pipeline runs

Values
Enum Value Description

SUBMITTED

 Pipeline waiting to be run

SCHEDULED

 Pipeline waiting to be run at a certain time in the future

RUNNING

 Pipeline currently running on the system

FAILED

 Pipeline run ended with a failure

COMPLETED

 Pipeline run complete successfully

KILLED

 Pipeline run aborted by the user
Example
"SUBMITTED"
Types

RuntimeConfiguration

Fields
Field Name Description
cpuAllocation - Int
memAllocation - Int
Example
{"cpuAllocation": 4000, "memAllocation": 8192}
Types

RuntimeConfigurationInput

Fields
Input Field Description
datasets - [String]!
resources - RuntimeResourcesInput!
Example
{"datasets": [], "resources": RuntimeResourcesInput}
Types

RuntimeResourcesInput

Description

Describe the computer resources needed by the datalab, input from the developer or user

Fields
Input Field Description
cpuAllocation - Int! The number of millicores needed
memAllocation - Int! The number of Mib needed
gpuAllocation - Int The number of GPU needed (This is not used yet)
Example
{"cpuAllocation": 4000, "memAllocation": 8192, "gpuAllocation": 2000}
Types

Schedule

Description

Schedule that triggers new pipeline runs at pre-defined time

Fields
Field Name Description
owner - User The schedule creator, who launched the Pipeline
cronExpression - String Schedule cron expression that expresses the run creation time
interval - String The attribute 'interval' related logic has not been implemented. So filling this attribute has no effect on system logic. To be deprecated.
Example
{
  "owner": User,
  "cronExpression": "* * * * *",
  "interval": null
}
Types

ScheduleInput

Description

Schedule that triggers new pipeline runs at pre-defined time

Fields
Input Field Description
cronExpression - String Schedule cron expression that expresses the run creation time
interval - String The attribute 'interval' related logic has not been implemented. So filling this attribute has no effect on system logic. To be deprecated.
Example
{"cronExpression": "* * * * *", "interval": null}
Types

StepLog

Description

Log of particular pipeline step

Fields
Field Name Description
stepName - String Name of the pipeline step the execution of which the log describes
logs - [Log] Pipeline step execution log entries
Example
{"stepName": "command_input", "logs": [Log]}
Types

StepRun

Description

Metadata of a pipeline step run results

Fields
Field Name Description
name - String! Pipeline step name
startDate - DateTime Pipeline step execution start date
endDate - DateTime Pipeline step execution end date
logs - [StepLog] Pipeline step execution log entries
status - RunStatus Pipeline step execution status
Example
{
  "name": "command_input",
  "startDate": "2023-11-28T10:55:01.465926",
  "endDate": "2023-11-28T10:57:54.594466",
  "logs": [StepLog],
  "status": "COMPLETED"
}
Types

StopPipelineRunInput

Description

The pipeline run to be stopped

Fields
Input Field Description
id - ID! The unique identifier of pipeline run to be stopped
Example
{"id": "d94cafae-e907-47fd-9d41-23ef1798948c"}
Types

String

Description

The String scalar type represents textual data, represented as UTF-8 character sequences. The String type is most often used by GraphQL to represent free-form human-readable text.

Example
"some-value"
Types

SystemPipeline

Description

System pipeline metadata

Fields
Field Name Description
id - ID! Unique System Pipeline identifier
name - String! System pipeline name
description - String System pipeline description
version - SystemPipelineVersion! System pipeline version used for the run
owner - User! User metadata about the creator of the system pipeline
labels - [String] List of pipeline labels attached when pipeline version was published to the catalog
createdDate - DateTime! System pipeline creation date
lastModified - String System pipeline last modification date
clusterIds - [ID!]! Unique identfiers of clusters where the system pipeline is available for running
defaultExecutionEngine - ExecutionEngine The execution engine that us used when not specific execution engine is defined in the launch parameters
allowedRoles - [String!] List of roles which have the right to see and launch the system pipeline
Example
{
  "id": "94ce5c60-7c45-44d0-aa9e-430df28c87fe",
  "name": "BC_MCAM",
  "description": "This pipeline contains 2 steps: tm2raw_mcam and pds4_packager.",
  "version": SystemPipelineVersion,
  "owner": User,
  "labels": ["example-pipeline"],
  "createdDate": "2023-05-10T15:13:36.102336",
  "lastModified": "2023-05-10 15:14:23.097174",
  "clusterIds": ["c-m-m28vdqgf"],
  "defaultExecutionEngine": ExecutionEngine,
  "allowedRoles": ["pipeline-services/developer"]
}
Types

SystemPipelineCode

Description

The source code (version) that can be included in the system pipeline run

Fields
Field Name Description
owner - User! The source code creator for the system pipeline. Optional field
version - String! The version number or name of the system pipeline source code
description - String Source code commit description for the source code version
createdDate - DateTime! Date when the source code was committed to the source code repository
code - [Code]! Source code files' contents, such as CWL and scripts
entrypointFilename - String! The name of the main CWL file for the system pipeline source code
Example
{
  "owner": User,
  "version": "0.0.2",
  "description": "",
  "createdDate": "2023-03-08T09:21:14.261220",
  "code": [Code],
  "entrypointFilename": "BC_MCAM.pipeline.cwl"
}
Types

SystemPipelineCodeInput

Description

The source code (version) that can be included in the system pipeline run

Fields
Input Field Description
version - String! The version number or name of the system pipeline source code
code - [CodeInput]! Source code files' contents, such as CWL and scripts
entrypointFilename - String! The name of the main CWL file for the system pipeline source code
description - String Source code commit description for the source code version
Example
{
  "version": "0.0.2",
  "code": [CodeInput],
  "entrypointFilename": "BC_MCAM.pipeline.cwl",
  "description": ""
}
Types

SystemPipelineInput

Description

System pipeline metadata

Fields
Input Field Description
type - Type! What type of elements is provided as input: PIPELINE or STEP
name - String! System pipeline name
description - String System pipeline description
code - SystemPipelineCodeInput The source code (version) that can be included in the system pipeline run
labels - [String] List of pipeline labels attached when pipeline version was published to the catalogue
clusterIds - [ID!]! Unique identfiers of clusters where the system pipeline is available for running
defaultExecutionEngine - String! The execution engine that us used when not specific execution engine is defined in the launch parameters
allowedRoles - [String!] List of roles which have the right to see and launch the system pipeline
Example
{
  "type": "PIPELINE",
  "name": "BC_MCAM",
  "description": "This pipeline contains 2 steps: tm2raw_mcam and pds4_packager.",
  "code": SystemPipelineCodeInput,
  "labels": ["example-pipeline"],
  "clusterIds": ["c-m-m28vdqgf"],
  "defaultExecutionEngine": "CALRISSIAN",
  "allowedRoles": ["pipeline-services/developer"]
}
Types

SystemPipelineRunInput

Description

Input that defines what system pipeline and how it will be run

Fields
Input Field Description
runInput - PipelineRunInput! Input to be used for the pipeline run
systemPipelineId - ID! Unique identifier for the system pipeline to be run
systemPipelineVersion - String! Version name/number of the system pipeline to be run
Example
{
  "runInput": PipelineRunInput,
  "systemPipelineId": "db70a3e1-c605-44e0-8867-c77efa6a29a2",
  "systemPipelineVersion": "0.0.4"
}
Types

SystemPipelineVersion

Description

System pipeline version information used for system pipeline run input

Fields
Field Name Description
latestVersion - String! The version number or name of the latest available version for the source code of this system pipeline. Optional field
defaultVersion - String! The version number or name of the default version for the source code of this system pipeline which is used when specific version is not sepcified. Usually the latest version
codeVersion - SystemPipelineCode! The version of the system pipeline source code which is being being used in the run
Arguments
version - String
Example
{
  "latestVersion": "0.0.4",
  "defaultVersion": "0.0.2",
  "codeVersion": SystemPipelineCode
}
Types

TestPipelineRunInput

Description

Input that defines what test pipeline and how it will be run

Fields
Input Field Description
runInput - PipelineRunInput! Input to be used for the pipeline run
code - UserPipelineCodeInput! Source code and filename of the source code to be run
keepOutputDirectories - Boolean Keep intermediary output directories. Useful for developing and debugging multi step pipelines
Example
{
  "runInput": PipelineRunInput,
  "code": UserPipelineCodeInput,
  "keepOutputDirectories": false
}
Types

TriggerData

Description

User-specified running time in seconds after which user gets notification for Long running Pipeline

Fields
Field Name Description
limit - Int Limit in seconds
Example
{"limit": 600}
Types

TriggerDataInput

Description

User-specified running time in seconds after which user gets notification for Long running Pipeline

Fields
Input Field Description
limit - Int Limit in seconds
Example
{"limit": 600}
Types

Type

Description

Functional type of pipeline services element

Values
Enum Value Description

STEP

 The pipeline services element is of type Pipeline Step

PIPELINE

 The pipeline services element is of type Pipeline
Example
"STEP"
Types

UpdateAnnouncementInput

Description

Input variable values for the updating of the user interface announcement banner text.

Fields
Input Field Description
announcement - String! Announcement text. Allows insertion of HTML tags to format the text.
textColorCode - String Color of the announcment text characters. Hexadecimal triplet in format #RRGGBB.
backgroundColorCode - String Color of the announcment text background. Hexadecimal triplet in format #RRGGBB.
Example
{
  "announcement": "<br><center>Banner text update test 1</center></br>",
  "textColorCode": "#00008B",
  "backgroundColorCode": "#50EBEC"
}
Types

UpdateRoleInput

Description

Input for updating existing Role

Fields
Input Field Description
cosmosLdapGroup - String Cosmos LDAP group to synchronize members from
Example
{"cosmosLdapGroup": "XYZ Datalabs Member"}
Types

UpdateSystemPipelineInput

Description

The system pipeline to be updated

Fields
Input Field Description
id - ID! Identifier of the system pipeline to be updated
pipelineInput - SystemPipelineInput The pipeline data to be changed during the update
Example
{
  "id": "94ce5c60-7c45-44d0-aa9e-430df28c87fe",
  "pipelineInput": SystemPipelineInput
}
Types

User

Description

Basic information about a user. Used to display the user name and allow or restrict access to functions or data.

Fields
Field Name Description
username - ID The login name used by the user to login to the system.
displayName - String The full name of the user - first name(s) last name (s)
roles - [Role] The user access roles added to the user to allow access to system functions and/or specific data.
Example
{
  "username": "etestuser",
  "displayName": "EDL Test User",
  "roles": [Role]
}
Types

UserComment

Description

Comment for a datalab

Fields
Field Name Description
datalab_id - ID! The datalab which the comment belongs to
build_version - String! The build version the comment was done for
modified_at - String! When the comment was created/edited
comment - String! the content of the comment
user - User! Who did the comment
Example
{
  "datalab_id": "0cc7edf6-736b-42f6-891f-f395cc7896bc",
  "build_version": "1.0.2",
  "modified_at": "1715697428.874147",
  "comment": "Great!",
  "user": User
}
Types

UserDetails

Fields
Field Name Description
userSession - UserSession! Details of user session that can be used to authenticate as the user
user - String! Username in EDL
workspace - UserWorkspace! Users workspace details
Example
{
  "userSession": UserSession,
  "user": "etestuser",
  "workspace": UserWorkspace
}
Types

UserPipeline

Description

Pipeline hosted only in the user my workspace

Fields
Field Name Description
owner - String! The name of the user who created and hosts the pipeline in his/her personal workspace
code - UserPipelineCode! The source files content used when launching the user pipeline
Example
{"owner": "etestuser", "code": UserPipelineCode}
Types

UserPipelineCode

Description

The source code that is used within the user created pipeline

Fields
Field Name Description
entrypointFilename - String! The main CWL file name of the user pipeline
code - [Code]! Source file content, such as CWL file content and scripts
Example
{
  "entrypointFilename": "BC_MCAM.pipeline.cwl",
  "code": [Code]
}
Types

UserPipelineCodeInput

Description

The source code that is used within the user created pipeline

Fields
Input Field Description
entrypointFilename - String! The main CWL file name of the user pipeline
code - [CodeInput]! Source file content, such as CWL file content and scripts
Example
{
  "entrypointFilename": "BC_MCAM.pipeline.cwl",
  "code": [CodeInput]
}
Types

UserPipelineRunInput

Description

Input that defines what user pipeline and how it will be run

Fields
Input Field Description
runInput - PipelineRunInput! Input to be used for the pipeline run
code - UserPipelineCodeInput! Source code and filename of the source code to be run
Example
{
  "runInput": PipelineRunInput,
  "code": UserPipelineCodeInput
}
Types

UserSession

Fields
Field Name Description
session - ID! User session that can be used to authenticate as the user. Can be revoked by EDL or user
expiryDate - DateTime! DateTime (UTC) until the user session is valid (will be set in redis)
Example
{
  "session": "644b8a1b-4bd7-4cdb-b088-2b24a049c196",
  "expiryDate": "2024-09-12T12:17:27.816298"
}
Types

UserWorkspace

Fields
Field Name Description
uid - Int! Users uid number in the EDL system
gid - Int! Users gid number in the system, usually same as uid
path - String! Path to users workspace from file browser home path '{url}/api/resources/{path}'
url - String! URL to user's file browser
Example
{
  "uid": 77777,
  "gid": 77777,
  "path": "my_workspace",
  "url": "/datalabs/7adb2f056b8f487a"
}
Types

VersionInfo

Description

ESA Datalabs software version information

Fields
Field Name Description
version - String Version number or version name
repository - String Contains the 'git status' and 'git log --oneline -n 15' command output for the master branch of the ESA Datalabs source code main repository (called SEPP). It allows to determine which version (after which commit exactly) of the master branch has been deployed to the environment and if there are any master branch commits after the version whcih has been deployed.
Example
{
  "version": "0.8.0",
  "repository": "On branch release/EDL-0.11.0\nYour branch is up-to-date with 'origin/release/EDL-0.11.0'.\nnothing to commit, working tree clean\n\n\ne3611107 Remove the comment inside the SVG\n2b9cda7f Fix DLNAME not avaialbe\nb49f47b9 Add a new service with readable name\n24ab16f5 Pull request #468: SEPPPCR-1512 Search app queries single app instead of all from rancher\n56d6753c SEPPPCR-1512 Search app queries single app instead of all from rancher\nbf8c3165 Remove the function to force the values\n727a0e33 SEPPPCR-1431: Fix resources when not having unig\ned6d1bb6 SEPPPCR-1431 Fix resources setup when the runtimeconfiguration was never set\n7479692a SEPPPCR-1431 Fix resources quota\n07d1dadb SEPPPCR-1431 Fix issue with milicore\n02bc0dde Pull request #455: Dld 20240212 hotfix\n0c750a6c SEPPPCR-1327&904 Update metadata field definition\nc8dba4ff SEPPPCR-1340 Add probes to the destroy\n5a66c008 SEPPPCR-1431 Fixing default CPU in milicore\n81727f23 Pull request #450: SEPPPCR-1446 Fix datalab access time on resume\n"
}
Types

Vocabulary

Description

Recognized JSON-LD vocabularies. List of allowed Vocabulary types.

Values
Enum Value Description

INTERNAL

 Data is expressed in the system internal representation (fastest)

SDO

 Data is expressed using schema.org vocabulary

DCAT

 Data is expressed using DCAT vocabulary
Example
"INTERNAL"
Types

Workspace

Description

Basic information for a workspace = a collection of files and folders for read/write by the EDL user

Fields
Field Name Description
workspaceID - ID! Unique identifier of the workspace across data centres
workspaceName - ID! Visible name of the workspace. In the user interface the field is called 'Workspace identifier' ('Team Workspace Settings' modal window) or 'Short name' ('Update Team' modal window).
metadata - String! All the fields describing the Team. Like: Title, Short name, Domain, DCMI Tyme etc
members - [User!]! List of users who are either members or managers of the team
Example
{
  "workspaceID": "55000",
  "workspaceName": "AWorkspaceTest2",
  "metadata": "{\"title\":\"AWorkspaceTest2 title 1\",\"alternateName\":\"AWorkspaceTest2\",\"type\":\"https://data.esa.int/esado/Team\",\"description\":\"AWorkspaceTest2 description 1 AWorkspaceTest2 description 1 AWorkspaceTest2 description 1 AWorkspaceTest2 description 1 AWorkspaceTest2 description 1 AWorkspaceTest2 description 1\"}",
  "members": [User]
}
Documentation by Anvil SpectaQL