How to Deploy RudderStack Transformations with GitHub Actions
Automate transformation testing and deployment with GitHub Actions.
4 minute read
RudderStack’s Transformation Action lets you create, update, test, and publish transformations and libraries written in JavaScript or Python - directly from your development repository. Internally, this action leverages the Transformations API.
This action is currently available for GitHub only.
| Resource | Permission | Description |
|---|---|---|
| Transformations | Edit | Make changes to the configuration of transformations |
| Transformations | Connect | Connect a transformation to a destination |
| Transformations | Create & Delete | Create or delete transformations |
| Transformation Libraries | Edit | Make changes to the configuration of transformation libraries |
Click here to see how these permissions appear in the workspace policy.

For security purposes, RudderStack recommends using GitHub secrets to store your Service Access Token.
If you are on the legacy Permissions Management (RBAC) system, your workspace-level Service Access Token should have Admin role with Grant edit access setting toggled on under Transformations.
See this documentation for more information on generating the token.

See the sample workflow for more information on using the action.
name: RudderStack Transformer Test and Publish
uses: rudderlabs/rudder-transformation-action@<current_action_version>
with:
metaPath: './code/meta.json'
email: 'test@rudderlabs.com'
accessToken: ${{ secrets.ACCESS_TOKEN }}
uploadTestArtifact: true
Specify the email address and Service Access Token obtained in the Prerequisites section in the email and accessToken fields respectively.
See FAQ for more information on the uploadTestArtifact parameter.
| Field | Description |
|---|---|
metapathRequired | Path to the meta file that:
|
emailRequired | Email address associated with the RudderStack workspace. |
accessTokenRequired | Your Service Access Token obtained from the RudderStack dashboard. |
uploadTestArtifact | Boolean flag that determines:
uploadTestArtifact parameter for more information.Default value: False |
As mentioned above, a meta file lets the transformation action know what transformations or libraries to test depending on the input events and the expected output.
A generic meta file schema is shown below:
// Meta file schema
{
"transformations": <array of transformation schema>,
"libraries": <array of library schema>
}
A sample meta file is shown below:
// example meta.json
{
"transformations": [
{
"file": "./code/t1.js",
"name": "action-T1",
"language": "javascript",
"description": "action-T1",
"test-input-file": "./code/testevents.json",
"expected-output": "./code/expectedoutput.json"
},
{
"file": "./code/t2.py",
"name": "action-T2",
"language": "pythonfaas",
"description": "action-T2",
"test-input-file": "./code/events.json",
"expected-output": "./code/expected.json"
}
],
"libraries": [{
"file": "./code/lib1.js",
"name": "lib1",
"language": "javascript",
"description": "action-lib1"
},
{
"file": "./code/lib2.py",
"name": "getFinanceDataPy",
"language": "pythonfaas",
"description": "Python library to get finance data"
}
]
}
The path mentioned in thefilefield should be relative to the base repository path.
The transformations parameter in the meta file contains an array of transformation schemas. A single transformation schema contains the following parameters:
| Parameter | Description |
|---|---|
fileRequired | Path to the transformation code. |
nameRequired | Transformation name. |
languageRequired | Transformation language. Permissible values are javascript and pythonfaas. |
description | Transformation description. |
test-input-file | Path to the JSON file containing an array of events to test the transformation. |
expected-output | Path to the JSON file containing the expected output for the above input, after running the transformation code. |
The libraries parameter in the meta file contains an array of library schemas. A single library schema contains the following parameters:
| Parameter | Description |
|---|---|
fileRequired | Path to the library code. |
nameRequired | Library name that you must specify to import it in any transformation. |
languageRequired | Library language. Permissible values are javascript and pythonfaas. |
description | Library description. |
uploadTestArtifact parameter?When you set uploadTestArtifact to true in the transformation action, RudderStack:
test-input-file.expected-output.Note that:
- RudderStack stores the output from Step 1 in a
[transformation name in camel case]_output.jsonfile.- It stores the validation differences from Step 3 in the respective
[transformation name in camel case]_diff.jsonfile.- If you do not set
uploadTestArtifacttotruein the transformation action, RudderStack does not create the output zip containing the above files.For more context, see the use case below.
Consider the following transformation schema:
// single transformationSchema
{
"file": "./code/t1.js",
"name": "action-T1",
"language": "javascript",
"description": "action-T1",
"test-input-file": "./code/testevents.json",
"expected-output": "./code/expectedoutput.json"
}
The workflow when you set uploadTestArtifact to true is as follows:
RudderStack runs the transformation action-T1(with its code present in t1.js) on the testevents.json file.
RudderStack then:
actionT1_output.json. This file is stored in a test-outputs folder contained within a zipped artifact.expectedoutput.json file. It stores any differences in a file named actionT1_diff.json.The test-outputs folder contains the two files -actionT1_output.jsonandactionT1_diff.json.
Automate transformation testing and deployment with GitHub Actions.