Awesome
JupiterOne Integration
Learn about the data ingested, benefits of this integration, and how to use it with JupiterOne in the integration documentation. The askJ1 community also has documentation on Jira integrations here: Jira integration with JupiterOne
Prerequisites
Steps to running the graph-jira locally
-
Install Node.js using the installer or a version manager such as nvm or fnm. Be sure to use Node version 18.x.
-
Install dependencies with
yarn install
. -
Register an account in the system this integration targets for ingestion and obtain API credentials.
-
cp .env.example .env
and add necessary values for runtime configuration.When an integration executes, it needs API credentials and any other configuration parameters necessary for fetching data from the provider. The names of these parameters are defined in
src/instanceConfigFields.ts
. When executed in a development environment, values for these parameters are read from Node'sprocess.env
, loaded from.env
. That file has been added to.gitignore
to avoid committing credentials.
Development
Running the integration
yarn start
to run integration and collect datayarn graph
to show a visualization of the collected datayarn j1-integration -h
for additional commands
Making Contributions
Start by taking a look at the source code. The integration is basically a set of functions called steps, each of which ingests a collection of resources and relationships. The goal is to limit each step to as few resource types as possible so that should the ingestion of one type of data fail, it does not necessarily prevent the ingestion of other, unrelated data. That should be enough information to allow you to get started coding!
See the SDK development documentation for a deep dive into the mechanics of how integrations work.
See docs/development.md for any additional details about developing this integration.
Versioning this project
This project is versioned using auto.
Versioning and publishing to NPM are now handled via adding GitHub labels to pull requests. The following labels should be used for this process:
- patch
- minor
- major
- release
For each pull request, the degree of change should be registered by applying the appropriate label of patch, minor, or major. This allows the repository to keep track of the highest degree of change since the last release. When ready to publish to NPM, the PR should have both its appropriate patch, minor, or major label applied as well as a release label. The release label will denote to the system that we need to publish to NPM and will correctly version based on the highest degree of change since the last release, package the project, and publish it to NPM.
Changelog
The history of this integration's development can be viewed at CHANGELOG.md.