Locally testing snap-ins
To test out changes in snap-in locally, developers can create a snap-in version in test mode. A snap-in version created in test mode enables developers to specify a public HTTP URL to receive events from DevRev. This makes for quick code changes on the local machine without needing to repeatedly deploy the snap-in again for testing the changes.
To set up the framework, the developer needs to
- Run the server local server present in the template on the mentioned port.
- Expose this port to a public URL.
- Create a snap-in version in test mode mentioning this URL.
Setting up the server
To test out a snap-in version locally, follow the below steps:
- Run a server locally to ingest events from DevRev. The
port
parameter is optional. If not set, the server starts default on8000
.
- Expose the local port as a publicly available URL. We recommend using
ngrok
since it is free and easy to set up. The command for running ngrok tunnelling on port8000
:
This returns a public HTTP URL.
- Create a snap-in version with the
testing-url
flag set
Here, HTTP_URL
is the publicly available URL from Step 2. The URL should start with http
or https
. Do note that
the developer cannot use the path
and testing-url
flags together.
- Once the snap-in version is ready, create a snap-in, update, and activate it.
Update the snap-in through UI or using the CLI:
Activate the snap-in through UI or the CLI command:
Receiving events locally
After the snap-in has been activated, it can receive events locally from DevRev as a
snap-in would. If the snap-in is listening to work_created
event type, then creating a
new work-item would send the event to the local server.
If utilizing ngrok, accessing the ngrok UI is possible by opening http://127.0.0.1:4040/ in the browser. This interface offers a neat way to review the list of requests and replay them if necessary.
The service account token included with the request is valid for only 30 minutes. Therefore, attempting to call the DevRev API with that token for events older than this timeframe will result in a ‘401 Unauthorized’ error.
Updating manifest or the URL
The code can be changed without the need to create a snap-in version or redeploy the snap-in. On any change to the
src
folder, the server restarts with the updated changes. However, on patch compatible updates to the manifest or the testing URL, we can upgrade
the snap-in version.
In case of non-patch compatible updates, the force
flag can be used to upgrade the version. However, this will delete any
existing snap-ins that have been created from this version.
Do note that manifest must always be provided when upgrading a snap-in version.