GEP is introducing a dedicated GitLab workspace to support the development, integration, documentation, and reuse of technical resources connected to the Geohazards Exploitation Platform.
The GitLab workspace is intended for expert users and contributors who develop processing services, prepare notebooks, maintain reusable tools, integrate scientific toolboxes, or collaborate within a GEP subscription or sponsored access activity.
It complements other GEP capabilities such as the Drive, cloud-hosted workspaces, processing services, and the portal. While the Drive is used to organise files and processing outputs, GitLab is used to manage code, workflows, documentation, notebooks, issues, and version-controlled collaboration.
Why GEP uses GitLab
Geohazard analysis often involves more than running a single service. Users and contributors may need to manage processing workflows, scripts, notebooks, configuration files, validation material, documentation, and reusable software components.
GitLab provides a structured way to organise this material and make it easier to maintain, review, improve, and reuse over time.
The GEP GitLab workspace supports:
- version control for code, notebooks, and workflow definitions;
- collaborative development through issues, branches, and merge requests;
- documentation and examples for services and tools;
- integration of EO Application Packages and processing workflows;
- reusable utilities for data discovery, product handling, and analysis;
- time-bound collaboration spaces for subscriptions, ESA NoR support, and project-based access.
Proposed top-level structure
The GEP GitLab workspace is organised around five main groups:
gep/
├── app-packages/
├── notebooks/
├── tools/
├── suites/
└── subscriptions/
Each group has a specific role in the platform ecosystem.
Application Packages
gep/app-packages/
The app-packages group contains EO Application Packages that can be exposed as GEP processing services.
An Application Package is the version-controlled source of a processing service. It brings together the workflow definition, service metadata, runtime environment, source code or wrappers, examples, tests, and documentation needed to build, validate, deploy, and execute a service on GEP.
Typical examples include:
- Sentinel-1 interferogram generation;
- InSAR time-series processing;
- flood extent mapping;
- wildfire hotspot detection;
- burned area mapping;
- burned area severity analysis;
- volcano deformation workflows;
- optical spectral index generation.
Application Packages are different from notebooks or tools. A notebook is usually used for exploration, demonstration, or analysis. A tool is a reusable helper library or utility. An Application Package is intended to become an executable service that can be registered, deployed, and run through the platform.
Notebooks
gep/notebooks/
The notebooks group contains Jupyter notebooks and analysis examples.
These repositories are intended for learning, demonstration, validation, and exploratory analysis. They may show how to search for EO data, inspect processing results, use products from the Drive, visualise outputs, or reproduce a specific analysis workflow.
Typical examples include:
- getting started with GEP;
- searching Sentinel-1 or Sentinel-2 data;
- inspecting service results from the Drive;
- opening products in QGIS;
- analysing earthquake interferograms;
- reviewing wildfire vegetation recovery;
- validating flood mapping outputs.
Notebooks are not necessarily operational services. They are practical resources that help users understand, test, document, and extend GEP workflows.
Tools
gep/tools/
The tools group contains reusable utilities, helper libraries, clients, and technical components that support GEP workflows.
These tools may be used by notebooks, Application Packages, service integrators, or platform operators.
Typical examples include:
- STAC query utilities;
- GEP API or Python clients;
- event metadata helpers;
- QGIS style templates;
- Application Package helper scripts;
- product validation utilities;
- Drive integration examples.
A tool is not necessarily a platform service on its own. It is a reusable building block that helps users and developers work more efficiently across the GEP environment.
Suites
gep/suites/
The suites group is used for persistent scientific toolboxes or integrated software suites.
This is useful when an external or community toolbox is integrated into GEP and should remain available beyond the lifecycle of a specific subscription, ESA NoR activity, or integration support action.
For example, a toolbox such as AMSTer could be organised as:
gep/suites/amster-suite/
A suite may contain several related components, such as Application Packages, notebooks, wrappers, configuration files, examples, documentation, and integration material.
Suites are different from individual Application Packages because they represent a broader, persistent capability. They may include several services or workflows around the same scientific toolbox.
Subscriptions
gep/subscriptions/
The subscriptions group contains time-bound or user-specific collaboration spaces linked to GEP access activities.
This may include ESA NoR-sponsored access, APEx-supported access, commercial subscriptions, demonstrations, training activities, or other supported service activities.
Examples could include:
gep/subscriptions/nor-2026-00123/
gep/subscriptions/apex-2026-volcano-monitoring/
gep/subscriptions/sub-2026-grid-resilience/
gep/subscriptions/demo-2026-earthquake-monitoring/
These groups are useful when users need a dedicated collaboration space for a specific activity, but the material is not necessarily intended to become a reusable GEP service or platform component.
Subscription follows a specific lifecycle and these time-bound collaboration spaces that can be archived, with reusable outputs promoted to long-term assets.
When the subscription or support activity ends, the group can be archived. If reusable material is produced, it can be moved or copied into the appropriate long-term group, such as app-packages, notebooks, tools, or suites.
How the groups work together
The groups are designed to support different parts of the GEP workflow.
A user may start from a notebook, use a tool to query a catalogue, run an Application Package as a processing service, inspect results in the Drive, and manage code or documentation in GitLab.
A service provider may develop a new Application Package, create example notebooks, publish helper tools, and support selected users through a subscription group.
A toolbox maintainer may contribute to a persistent suite, while GEP operators manage the integration and documentation needed to expose it through the platform.
The structure is intended to keep reusable platform assets separate from temporary collaboration spaces.
Recommended use
Use app-packages for processing services that can be deployed and executed on GEP.
Use notebooks for examples, tutorials, analysis workflows, validation material, and reproducible demonstrations.
Use tools for reusable code, clients, utilities, templates, and helpers.
Use suites for persistent integrated toolboxes that include multiple components or workflows.
Use subscriptions for time-bound access spaces, ESA NoR activities, APEx-supported access, commercial subscriptions, demonstrations, or user-specific collaboration.
Access and collaboration
Access should be granted according to the minimum permission level needed for each role.
External collaborators should normally be added only to the specific project, suite, or subscription group they need. Broad access to the top-level GEP GitLab group should be limited to platform administrators and trusted maintainers.
Contributors should use branches and merge requests for shared repositories, avoid storing credentials or secrets in Git repositories, and keep documentation up to date so that services, notebooks, and tools remain reusable.
A workspace for expert collaboration
The GEP GitLab workspace is part of the wider GEP environment for expert users.
Together with the Drive, processing services, cloud-hosted workspaces, and the portal, GitLab helps organise the technical assets behind GEP workflows. It supports the development of reusable services, scientific notebooks, toolbox integrations, and user-specific collaboration spaces.
The goal is to make GEP easier to extend, easier to document, and easier to use for collaborative geohazard analysis.
This proposed GitLab organisation is intended to support the development and reuse of GEP Application Packages, notebooks, tools, persistent scientific suites, and subscription-based collaboration spaces.