If you don’t know how to create Github action workflow and add a action to it, you can examine related page on Github docs.
Adding Validate Action To Your Workflow
After adding permify-validate-action to your Github Action workflow, you need to define the schema validation yaml file as,- With local file:
- With external url:
If you don’t know how to create Github action workflow and add a action to it, you can examine quickstart page on Github docs.
Schema Validation File
Below you can examine an example schema validation yaml file. It consists 3 parts;schema
which is the authorization model you want to test,relationships
sample data to test your model,scenarios
to test access check queries within created scenarios.
Defining the Schema:
You can define theschema
in the YAML file in one of two ways:
-
Directly in the File: Define the schema directly within the YAML file.
-
Via URL or File Path: Specify a URL or a file path to an external schema file.
Example with URL:
Example with File Path:
schema
and relationships
sections of the above YAML file. If not, please see the previous sections to learn how to create an authorization model (schema) and generate data (relationships) according to it.
We’ll continue by examining how to create scenarios.
Creating Test Scenarios
You can create multiple access checks at once to test whether your authorization logic behaves as expected or not. Besides simple access checks you can also test subject filtering queries and data (entity) filtering with it. Let’s deconstruct thescenarios
,
Scenarios
Access Check
You can createcheck
inside scenarios
to test multiple access check cases,
user:1
can push to repository:3
, additional to stored tuples take account that user:1 is owner of repository:3 (repository:3#owner@user:1
). Expected result for that check it true - push : true
We use
context
(Contextual Tuples) with simple relational tuples for simplicity in this example. However, it is primarily used for dynamic access checks, such as those involving time, date, or IP address, etc.To learn more about how context
works, see the Contextual Tuples section.Entity Filtering
You can createentity_filters
within scenarios
to test your data filtering queries.
check
lies in the assertions part. Since we’re performing data filtering with bulk data, instead of a true-false result, we enter the IDs of the resources that we expect to be returned
Subject Filtering
You can createsubject_filters
within scenarios
to test your subject filtering queries, a.k.a which users can perform action Y or have permission X on entity:Z?
You can find the related API endpoints for
check
, entity_filters
, and subject_filters
in the Permission service in the Using The API section.Coverage Analysis
By using the commandpermify coverage {path of your schema validation file}
, you can measure the coverage for your schema.
The coverage is calculated by analyzing the relationships and assertions in your created model, identifying any missing elements.
The output of the example provided above is as follows.

Testing in Local
You can also test your new authorization model in your local (Permify clone) without using permify-validate-action at all. For that open up a new file and add a schema yaml file inside. Then build your project with, runmake build
command and run ./permify validate {path of your schema validation file}
.
If we use the above example schema validation file, after running ./permify validate {path of your schema validation file}
it gives a result on the terminal as:

AST Conversion
By utilizing the commandpermify ast {path of your schema validation file}
, you can effortlessly convert your model into an Abstract Syntax Tree (AST) representation.
The conversion to AST provides a structured representation of your model, making it easier to navigate, modify, and analyze. This process ensures that your model is syntactically correct and can be processed by other tools without issues.
The output after running the above example command is illustrated below.