Skip to main content

Custom Modules

You can deploy your module with your own functionality using the developer API.

Development​

Use the template at https://github.com/OneEntry/module-example and follow the instructions at https://github.com/OneEntry/custom-module-deployment-guide during development.

Build​

  • Create a new project token with read-registry permissions. It is recommended to create a permanent token.
  • Create a new tag in git (with each release of a new version of the module).
  • Wait for the pipeline to complete, after which the docker image of the module will be uploaded to the registry and available for deployment.

Deployment​

Go to the settings, tab Modules, and scroll down to the card Create New Module.

  • Specify the name (Name) and marker (Marker) of the module.

  • In the Docker image block, in the Image URL field, specify the path to the previously built docker image in the format host/user/repo:version.

    Where host is the name of the docker registry host, for example registry.gitlab.com,

    user is the user or organization ID, for example oneentry,

    repo is the name of the repository, for example my-module,

    version is the tag name (module version).

    A full example: registry.gitlab.com/oneentry/my-module:v1.0.0

  • In the Registry host field, specify the docker registry host, which repeats the host part in the path to the docker image, for example registry.gitlab.com.

  • In the Token ID and Token fields, specify the name of the token (as indicated during creation) and the token itself (usually starts with glpat), respectively.

  • In the Environment Variables block, click Add and specify the environment variables required for the module to work (these can be changed later).

Click Create.

After creating the module, it will appear in the table. You can now deploy it by clicking Deploy (this will take some time).

Container Statuses​

  • Not deployed — the module has been created but has not yet been deployed.
  • Deploying — the module is in the process of being deployed.
  • Running — the module is operational.
  • Suspended — the module has been deployed but is not running.
  • Error — the last action with the module failed, see the section “Debugging Errors”.

While an action is being performed on the module, its status is displayed in the status column: Deploying, Suspending, Resuming, or Deleting. A status that could not be retrieved is displayed as Unknown. Statuses are updated automatically.

Module Actions​

  • Suspend Suspend the module. Stops the process, but the data remains.
  • Resume Resume the module. Starts the process.
  • Delete Delete the module. Stops the process, deletes the container, and associated data.

Debugging Errors​

If the module fails to deploy or the process consistently terminates, the module will receive an Error status, and a warning icon Warn will appear in the row with the tooltip “The last action with this module was unsuccessful.” A module in Error status, like an undeployed one, again has the deploy button Deploy: fix the issue and redeploy the module.

Possible Issues​

  • The docker image is incorrectly configured.
  • The token is invalid or incorrect.
  • The process terminates. The internal process should not terminate while the module is active.

Logging​

You can debug other issues with the module using the logs displayed in the module settings.

Updating/Editing the Module​

If you need to deploy a new version of the module or change the environment variables, you must update the tag and/or variables in the settings. The process will be restarted.