fix: skip validation of secondary instances without context
Created by: ashleythedeveloper
This PR fixes #313 (closed) and also addresses a secondary issue that was hidden by the primary problem.
Primary Issue: Validation Pipeline Validating Too Much
Context
As described in #313 (closed), the validation pipeline was incorrectly validating all instances in the payload, not just the primary sample instance. Secondary instances lacking a @context
caused the pipeline to fail when the JSON-LD processor attempted to expand them.
Fix
I've introduced a JARGON_INSTANCES_TO_VALIDATE
variable that explicitly lists which sample instance names should be validated.
The code now filters the payload to validate only those named instances, ignoring all others within the JSON-LD expansion step.
This approach was chosen because:
- The instance order is not guaranteed.
- There is no identifier marking the “primary” instance.
- The primary instance’s name is user-defined and not derived from the domain name.
While I considered making this configurable via an environment variable, I decided to keep it under version control to avoid accidental or unwanted changes.
Secondary Issue: Unable to Fetch Context
Context
Even after isolating the primary instance, the JSON-LD validation step failed because it couldn’t fetch the remote UNTP context.
This was due to the context file not being published at the specified IRI:
- IRI is set to
https://test.uncefact.org/vocabulary/untp/{{CREDENTIAL_ACRONYM}}/{{version}}/
as per domain settings in Jargon. - However, per our updated release workflow, we no longer release directly to
test.uncefact.org/vocabulary/untp/
, we now publish the context files to this repository, validate the artifacts in the pipeline, and then publish totest.uncefact.org/vocabulary/untp/
.
Fix
I've introduced a JARGON_CONTEXT_IRI_PREFIX
variable set to https://test.uncefact.org/vocabulary/untp/
to detect and replace the IRI.
The code now reads the @context
array and rewrites any IRI matching that prefix to use the Jargon-hosted context file provided in the payload.
The pipeline works as expected and has been tested with the available payloads from previous failed workflows.