defender-client
defender-client copied to clipboard
Monorepo for all defender-client npm packages
Defender Client Packages
Monorepo that contains Defender typescript clients. Check out the individual packages for more info:
- defender-admin-client
- defender-autotask-client
- defender-autotask-utils
- defender-kvstore-client
- defender-relay-client
- defender-sentinel-client
Development Setup
Checkout the repo and run yarn && yarn build.
Testing
Run yarn test to run unit tests across all packages.
Linting
Run yarn lint at the project root.
Publish
Defender Client
We Use
lernafor publishing a new version of all Defender Client packages (excludes Platform Deploy Client as it is versioned separately).
- We use github actions for CI/CD to tag, release & publish the packages. See details about workflows below.
Platform Deploy Client
Change to the packages/deploy directory, login to npm, and publish using the native yarn publish command as shown below. We are not tagging versions for the time being as they conflict with previous Defender Client releases. Note this process is being introduced for the Platform Deploy Client v0 release, but will be migrated to a new Platform Client-specific repository.
To prepare a publish:
npm login
cd packages/deploy
git checkout master
git pull origin master
yarn build
To publish a release candidate:
yarn publish --new-version <version> --tag next # version should be of format 0.5.1-rc.1
And to publish the final release:
yarn publish --no-git-tag-version
# enter new version at prompt
git add package.json
git commit -m 'Bump Platform Deploy Client version to {version here}'
git push origin master
Examples
The examples repo has sample code for both clients. Note that most examples rely on dotenv for loading API keys and secrets. Note that you can set the following environment variables to control to which instance your client will connect to, which is useful for testing against your Defender development instance:
# Example config
# relay signer
DEFENDER_RELAY_SIGNER_API_URL=
DEFENDER_RELAY_SIGNER_POOL_ID=
DEFENDER_RELAY_SIGNER_POOL_CLIENT_ID=
# relay client
DEFENDER_RELAY_API_URL=
DEFENDER_RELAY_POOL_ID=
DEFENDER_RELAY_POOL_CLIENT_ID=
# admin client
DEFENDER_API_V2_URL= # same as DEFENDER_ADMIN_API_URL
DEFENDER_ADMIN_API_URL=
DEFENDER_ADMIN_POOL_ID=
DEFENDER_ADMIN_POOL_CLIENT_ID=
# autotask client
DEFENDER_AUTOTASK_API_URL=
DEFENDER_AUTOTASK_POOL_ID=
DEFENDER_AUTOTASK_POOL_CLIENT_ID=
# sentinel client
DEFENDER_SENTINEL_API_URL=
DEFENDER_SENTINEL_POOL_ID=
DEFENDER_SENTINEL_POOL_CLIENT_ID=
CI/CD
- We use github actions for CI/CD. See workflows for more info.
ci.yml- runs on every push to any branch --> runs tests.rc.yml- runs on every push to master --> creates a rc tag --> creates a pre-release draft.stable.yml- Manual trigger workflow --> creates a stable tag --> creates a latest release --> publishes to npm.release.yml- Manual trigger workflow --> create a git release for a given tag.publish.yml- Manual trigger workflow ( for any given tag ) --> publishes to npm.
Determinstic Builds & Secure Publishes
- We use slsa framework pronounced "salsa" for reproducible builds & secure pushes. Verification is done using provenance
Known Issues [Resolution in progress]
lerna publishwith github actions fails due to npm permission issues due to using 2fa. Currently we useNPM_TOKENin github actions which throws forbidden error. To overcome we use 2fa from local machine to publish the packages.