Integrate the files in your CI by setting them to trigger as follows:
| File name | Event trigger |
|---|---|
bit-init.sh | Start of every CI job |
verify.sh | On git push |
pull-request.sh | On new or modified PR |
tag-export.sh | On merge to main (approved PR) |
commit-bitmap.sh | After merge to main (commits changes in workspace, back. Make suer to use a comment to skip the CI) |
Create a permanent access token for your CI. Lean how in the generating an access token section.
Add the following environment variables to your CI system:
| Environment Variable | Value/Description | |
|---|---|---|
BIT_CLOUD_ACCESS_TOKEN | a bit.cloud access token with permission levels required for your workflow | |
BIT_CONFIG_INTERACTIVE | false | |
BIT_CONFIG_ANALYTICS_REPORTING | false | |
BIT_CONFIG_ANONYMOUS_REPORTING | false | |
GIT_USER_NAME | a username for git commits made by the CI | |
GIT_USER_EMAIL | an email for git commits made by the CI |
To learn more see the docs for this implementation of the workflow, or read the in-depth' section below.
Create a permanent access token for your CI with the proper permissions to install, import and export components in the relevant scopes.
Head over to your organization page on bit.cloud, then click on the 'settings' tab, and then on the 'access tokens' tab.
These steps should precede any sequence of CI steps that use Bit.
Install BVM globally
To troubleshoot installation issues, see BVM Troubleshooting section.
Set the PATH environment variable to include the BVM installation directory:
Install Bit globally
Turn off interactive mode
Alternatively, you can set the BIT_CONFIG_INTERACTIVE environment variable to false.
Turn off analytics reporting
Alternatively, you can set the BIT_CONFIG_ANALYTICS_REPORTING and BIT_CONFIG_ANONYMOUS_REPORTING environment variables to false.
Set your package manager to use the bit.cloud registry
Set your package manager to use the bit.cloud registry for Bit components. This should only be done if you plan to install Bit components using a package manager (instead of Bit). To learn more see installing components.
The above shows how to set npm to use the bit.cloud registry fro components from
teambitand frommy-orgbit.cloud account (replacemy-orgwith your organization name or username).
Set a token for the bit.cloud registry:
Get the token of a user by running
bit config get user.tokenin the terminal, where the user is logged in.
The following steps should be executed on every push to the remote repository.
Strict status check
The CI should verify no issues are found in your workspace (e.g missing dependencies, etc).
Use the strict option to exit with code 1 when issues are found (use this exit code to stop the CI).
Build components
When developing in a local workspace, Bit prioritizes performance and dev experience for each component's test and build process. When you push any modified component to the branch, Bit needs to run the entire isolation process for each component.
The following steps should be executed on every new or updated pull-request.
Create a new lane
Create a new lane to make the changes available for review in a remote scope, isolated from the main lane.
In case of a PR update, a lane with the same ID already exists. To address that, it is better to verify first the lane is not available in the remote scope by running:
bit lane list --remote ACCOUNT.SCOPE. To remove the remote lane run:bit lane remove LANE_ID --remote.
Strict status check
The CI should verify no issues are found in your workspace (e.g missing dependencies, etc).
Use the strict option to exit with code 1 when issues are found (use this exit code to stop the CI).
Snap the components to the new lane
Build and snap components to the new lane.
Export the lane
Note that workspace changes are not committed back to the branch as they are only used for review and verification. The development in this branch is done on the main branch.
The components are available for review in the workspace's default remote scope at https://bit.cloud/ACCOUNT/SCOPE/~lane/LANE_ID.
The following steps should be executed on every merge to the main branch.
Tag components
Modified components are snapped and tagged with a semantic release version. Byt default, the patch number is increased. You can use the --minor or --major flags to increase the minor or major version numbers.
Export components
Commit changes back to repository
Once the modified components are tagged, the .bitmap file is updated with the components' new versions.
In addition, temporary component configurations that were added to the .bitmap file are removed, as they are now stored in the component snaps.
Include the bitmap file
Commit with Skip-CI
Ensure your CI system allows you to merge back to main while skipping the CI, to prevent an infinite loop.
Push changes
Push the latest changes to the origin repository.
