Skip to content
Home of Mozilla IAM change integration service repository.
Branch: master
Clone or download
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Type Name Latest commit message Commit time
Failed to load latest commit information.
.travis.yml add initialization logger Jan 23, 2019

CIS - Change Integration Service

Build Status CIS is the Mozilla IAM Change Integration Service.

I'm an API user, where do I start?

See PersonAPI docs for querying the API.

Build & Deploy (manual)

Available environment/stages are: development, testing, production (see below for more information)

$ make build STAGE=development
$ make release STAGE=development

Or you can deploy a single function as such, instead of running make release (note that you may still want to run make build which both builds and upload the Lambda layers:

$ make -C serverless deploy-ldap-publisher

Note that the build & release process happens automatically on the GitHub repository. The above steps are for manual deploys.

Test all python modules

This will take care of starting dynalite and other tools, then run tests in tox and clean itself up. If you get issues with node packages missing simply install them with npm install <package> prior to running this.

$ cd python-modules
$ make test-tox

Each module can also be individually tested:

$ cd python-modules/cis_profile
$ make test-tox

Other good-to-know testing options:

$ cd python-modules/cis_profile
$ tox -r # recreates the Python environment
$ tox -- ./tests/ # runs a single test file instead of all tests

The tox test environment is stored in python-modules/.cis-env by default

Test endpoints end-to-end

$ cd e2e
$ make test-tox

How changes are published to CIS


Additional Documentation & Resources

Where is what?

  • e2e contains the end to end tests for CIS. These are a good source of examples on how to use the CIS API.
  • python-modules contains several libraries which can be called on their own. Many are inter-dependent.
  • serverless-functions are lambda functions which load some of the python-modules into AWS Lambda.
  • well-known-endpoint contains the Mozilla IAM Well Known endpoint data and it's deployment methods (this endpoint can only be manually deployed)
  • buildspec.yml contains the AWS Codebuild CD scripts.
  • .travis.yml contains the Travis CI scripts.

Note that many directories contain their own, which has more detailed information.


These are the general docs for the concepts behind CIS.

Draft-RFCs & Proposals (informational-only)


Production (prod)

This is what you expect. Tagged releases (SemVer, e.g. 1.2.3) from this repository are what run in production. It uses a specific set of signing and verifications keys. This is the environment you will get access to if you request API access to CIS. This is also the environment that DinoPark and DinoPark Beta access.




Testing (testing)

This is what is usually called staging. It contains code and data similar to production and is used to ensure that the production deployment will work. It uses the same set of keys as production. This environment contains real data and is not guaranteed to persistent. In practice this means the data is reset periodically. This environment is meant for general QA.

Tagged releases (SemVer pre-releases, e.g. 1.2.3-pre) from this repository are what run in testing.




Development (dev)

This is for local testing and development. This is also what is in the master branch of this repository. It uses a development set of keys for signing and verification. This environment contains fake data and is neither persistent neither guaranteed to be stable, though it should be almost always functional. Access to this environment may be granted temporarily to diagnose specific issues, features, etc. as they're being developed, but is not meant for general QA.



You can’t perform that action at this time.