The version published at this time contains bugfixes to the previous version related to the INSPIRE Reference Validator and the Validator UI, please see them in detail:
🐛 Bugfixes
#1262 CSS not loading - etf-validator.net is not available
Deployment instructions
The section containing the deployment process using Docker image and troubleshooting section. You can also find these in the training material
docker login docker.pkg.github.com
#Provide Github credentials
docker run --name inspire-validator -d -p 8090:8090 -v ~/etf:/etf docker.pkg.github.com/inspire-mif/helpdesk-validator/inspire-validator:2026.1.1
#Launches a container from the specified image, exposing the UI on port 8090, mapped to the same port on the host.
Additionally, it mounts a local volume from ~/etf, which will result in an etf directory being created in the user's home folder if it does not already exist.Once the INSPIRE Reference Validator has fully loaded, we can access to it through the URL http://localhost:8090/validator/home/index.html
Please note that installation instructions for apt-get include --allow-unauthenticated parameter because the certificate of the Debian repository has expired, so this parameter is needed to download and install the tools properly.
Modifying the Docker image
In the inspire-validator ZIP file, you can find all the resources needed to generate the Docker image from this release. If you would like to tweak anything from it, you can modify any of its contents (Dockerfile, entrypoint file, configuration files... ), then execute (inside the ETF docker folder) the command
docker build . -t [IMAGE_NAME]:[VERSION]
You can run this again using the run command
docker run --name inspire-validator -d -p 8090:8090 -v ~/etf:/etf [IMAGE_NAME]:[VERSION]
Deployment on production host
The Docker image is set up to run at localhost to be deployed on any machine. However, users may need to access their validator on a dedicated host, usually with a domain name. For proper functioning of the validator, the UI and correct rendering of Test Reports, the validator needs to be configured to run on a domain.
If you want to run the webapp in another host, you can change the configuration file, inside the .war file inside the inspire-validator zip file accompanying this release, at WEB-INF/classes/etf-config.properties, and modify the etf.webapp.base.url property.
It is also necessary to configure the Validator UI properties in order to properly point to the ETF. Thus, it is necessary to modify the configuration values in the /validator/js/config.js file inside the ui.zip (to point to the corresponding host domain).
Then you can proceed to the build process described in the previous point.
Since 22/12/2022 OGC moved to production version 5.5.2 (2022-08-26) of the TEAM Engine, which introduced credentials for the calls to the services.
Thus, any deployment which makes use of the OGC TEAM Engine needs to introduce credentials (to be requested in the OGC Validator register page) in order to use them.
We have incorporated three parameters in the /WEB-INF/classes/etf-config.properties file of validator.war that need to be filled accordingly to authorize the use of the services:
#TEAM Engine credentials of your organization in order to properly use TEAM Engine remote calls
etf.testdrivers.teamengine.url = http://cite.opengeospatial.org/teamengine
etf.testdrivers.teamengine.username =
etf.testdrivers.teamengine.password =
Exposing the validator through a proxy
Usually, host machines are connected to a private network that accesses the Internet through a proxy. The Docker client needs to be configured to make use of this proxy, in order to be able to build the image and set up running the container.
For the build process, you need to add the following arguments to the command
--build-arg http_proxy=[HTTP_PROXY_URL:PORT] --build-arg https_proxy=[HTTPS_PROXY_URL:PORT] --build-arg no_proxy=127.0.0.1,localhost,*.<my-domain>
For the run command, you need to add the environment variables to it
--env http_proxy=[HTTP_PROXY_URL:PORT] --env https_proxy=[HTTPS_PROXY_URL:PORT] --env no_proxy=127.0.0.1,localhost,*.<mydomain>
These can also be set up in the Dockerfile, using the keyword ENV
For more information please check out https://docs.docker.com/network/proxy
For further configuration, please download the file inspire-validator-2026.1.1.zip and follow the instructions in the README.md file inside the .zip file.
Setting up a cache of INSPIRE Registry resources
In your own deployment you may want to increase the performance of fetching the different resources that the INSPIRE Reference Validator requires from the INSPIRE Registry for validations.
Attached is the file inspire-registry-resources.zip, which includes the resources that the INSPIRE Reference Validator requests to the INSPIRE Registry to execute the validations defined in the Executable Test Suites (ETSs).
Using this content, you may configure your own deployment to access these resources without the need to make a call to the INSPIRE Registry to obtain them, increasing the performance of your own instance while decreasing the dependency on external resources in your installation.
Example of setting up INSPIRE Registry resources as cache
In order to show how to use the Registry resources as cache, we have prepared a simple example.
The purpose of this example is to provide a foundation that can be adapted to an organization's proxy policies.
- Download the Registry resources below.
- Unzip the resources.
- Open a terminal and access the resources folder
- Publish the resources as an http server using, for example, Python:
python -m http.server 8000
- Once the resources are published, we can use any proxy reverse (nginx, apache, ...). We show you an example using fiddle:
function OnBeforeRequest(oSession: Session) { if (oSession.host == "inspire.ec.europa.eu") { oSession.host = "0.0.0.0"; oSession.port = 8000; oSession.url = oSession.url.replace("https://inspire.ec.europa.eu", "http://0.0.0.0:8000"); } }
This will ensure that all the Validator's requests to the Registry are redirected to the server, using these local Registry resources instead.