CI Environment

Continuous Integration is an important component of making Streamlit robust and stable. We are running a lot of tests for every pull request, for develop branch, and regularly as scheduled builds.

Python tests

Canary builds

Canary builds are tested on all Python versions and do not use constraints. Non-canary builds are tested by default on the oldest and latest Python versions and use constraints files by default.

The type of build depends on what event triggered the current GitHub Action build to run.

• For pull_request event, the build is canary when Python dependencies have been modified.
• For push event, the build is canary when the default branch is checked.
• For other events, the build is non-canary.

Build canary can be enforced by workflow inputs parameter e.g. all "Build Release" workflows trigger canary builds.

For details, see: ./github/scripts/build_info.py

Tested Python versions

Whether tests should be run against all supported Python versions or just checking the oldest and latest version depends on:

• Kind of build: Canary builds always check all Python versions.
• PR labels: If you want to check all Python versions, you can add the dev:full-matrix label

Python dependencies

For each build, a list of all Python dependencies that have been installed is generated, written to a file, and published as an Github artifact. In addition, for successful builds on develop branch, these files are also published on constraints-develop branch. This way, we track a tested and working set of dependencies. The list of dependencies is also called constraint files.

For the released version of Streamlit, the constraints files are stored in the constraints-release branch. Each release also has a constraints/<VERSION> tag.

Most pull requests are non-canary builds because they don't modify dependencies, so they use constraint files. Thanks to this, the release of new versions of dependencies does not affect the work of other people, and only one person can take care of dependencies issues. There are two cases that require more attention:

• If you modify dependencies in your PR then it is not possible to use constraints files so your PR build will be canary and will not use constraints files, so you will have the latest versions of dependencies.
• If you are working on a compatibility fix with a newer version of the library and you want to force the installation of the latest dependencies, you should add the label dev:upgrade-dependencies to PR.

If the build fails due to a new dependency and you're not sure which one exactly, you can see a comparison of your dependencies with the last ones checked in the GitHub Action logs in the "Diff constraints files" step in "Python Versions" workflow.

Playwright snapshots

You can use Github Action to update your snapshots, for details see: Use CI to generate snapshots.