This page presents a workflow for automating component release with Bit, Git and third-party CI systems.
In this workflow:
- Git is used as the source of truth for the code.
- The repository has a Bit workspace initialized in it. Some directories in the repository are maintained as Bit components.
- Features are developed in branches and merged to the main branch via pull-requests.
- Lanes are used to empower third-party tools for code review. They allow all stakeholders to review component preview, and test components in different apps and environments. See this demo PR with a lane for a component preview.
- New component releases are created when changes are merged to the main branch. These components are exported to remote scopes, where they are consumable by other projects.
See a full demo of this workflow using Github Actions, here.
Choose the right implementation for your CI system, or use the scripts as a base for your own implementation.
Download these files and place them in your repo's
.github/workflowdirectory. See the tasks in Github Marketplace.Add the following environment variables:
| Environment Variable | Value/Description |
|---|---|
GITHUB_TOKEN | a GitHub secret set with a GitHub token that has the permission levels required to perform the CI actions in your repository |
BIT_CONFIG_USER_TOKEN | a GitHub secret set with a Bit token that has the permission levels required for your workflow |
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.
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 a Bit token
Set an auth token for bit.cloud, with the proper permissions to export components to the relevant remote scopes.
Alternatively, you can set the BIT_CONFIG_USER_TOKEN environment variable to the token value.
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.
