Store Module definitions in Git repositories

Once you have multiple Module definitions, you might want to store them in a Git repository. Storing Module definitions in a Git repository allows for better collaboration and control over changes. It allows users to collaborate on Module definitions in a Git repository and require pull requests for any changes. This method ensures that all changes are reviewed and approved before being applied. Storing Module definition in a Git repository is not necessary if you would like individual users to be able to unilaterally create Modules.

The benefits of storing Module definitions in Git repositories include:

• Collaboration: Multiple users can work on Module definitions simultaneously.
• Review Process: Use pull requests to review and approve changes before they are merged.
• Automation: Integrate with CI/CD pipelines to automate validation and updates.

By leveraging the Apollo CLI, you can manage these definitions effectively. The Apollo CLI provides several commands that you can use to validate, update, and lock your Module definitions, ensuring consistency and enabling efficient collaboration across teams. These commands can be integrated into CI steps or used as Git pre-hooks to automate the management of Module definitions.

apollo-cli module create

The apollo-cli module create command is used to create or update a Module in Apollo. This command processes the Module definition file and creates the Module in Apollo.

For more details on creating Modules, refer to the Create a Module section.

Usage

Copied!
1
apollo-cli module create --module-definition-file /path/to/module-definition.yml

Dry-run

You can use the --dry-run flag to simulate the creation of the Module without actually publishing it. This is useful for validating the Module definition after making any changes.

Copied!
1
apollo-cli module create --module-definition-file /path/to/module-definition.yml --dry-run

apollo-cli module lock

The apollo-cli module lock command returns a flattened view of the Module definition that includes all the submodules, making it easier to view all the entities that will be included in your Module, even if they are nested. It also includes the list of all the variables that the Module will require during installation, including variables from any of the submodules. This flattened view is saved as a file with the same name as the Module definition and a .lock suffix.

When storing Module definitions in a Git repository, you should run this command as part of the pre-merge CI job to ensure that the lock files are required to exist and be up to date. This allows code reviewers to views changes to the Module definition, including changes to entities or variables from the submodules.

Usage

Copied!
1
apollo-cli module lock --module-definition-file /path/to/module-definition.yml

Verification

You can use the --verify flag to perform a verification check on the Module definition. This flag ensures that the existing .lock file is up-to-date by comparing it to the one that would be generated. If the two do not match, the command fails.

Copied!
1
apollo-cli module lock --verify --module-definition-file /path/to/module-definition.yml

apollo-cli module submodule-update

The apollo-cli module submodule-update command is used to update the submodule revisions within a composite Module. Because submodule definitions include the exact revision, this command can be used to periodically update all the revisions to latest. Once you do this, you must also run the module lock command to update the lock file with any potential changes due to the update to the submodules.

Usage

Copied!
1
apollo-cli module submodule-update --module-definition-file /path/to/composite-module-definition.yml

Copied!
1
2
3
4
5
6
7
8
9
10
name: example-composite-module
displayName: Example Composite Module
description: Example Composite Module
submodules:
   - name: "example-module-1"
-    revision: 0
+    revision: 2
   - name: "example-module-2"
-    revision: 1
+    revision: 3

In this example, example-module-1 has been updated from revision 0 to 2, and example-module-2 has been updated from revision 1 to 3. After updating the submodule revisions, you should run the module lock command to update the lock file with any potential changes due to the update to the submodules.