Some of our customers build software that's intended to run in CI/CD pipelines. It is important for them to have a good sense of which CI/CD tools their users are using their software in.
Most of our customers would also like to be able to filter on events fired from CI/CD or filter them out of their analyses.
I propose that, when we generate system tags, we try to detect whether we are running in a CI/CD environment and add the (inferred) name of the CI/CD provider (e.g. GitHub Actions, CircleCI, TravisCI, etc.) as a tag of the form ci:<provider>.
Each CI/CD platform has certain environment variables that it uses to configure internal processes:
- GitHub Actions
- Circle CI
- Travis CI
Note that all of them seem to set CI=true. So at the very least we should use that. We can also use the presence or absence of other environment variables to infer which specific CI provider we are working with.
Some of our customers build software that's intended to run in CI/CD pipelines. It is important for them to have a good sense of which CI/CD tools their users are using their software in.
Most of our customers would also like to be able to filter on events fired from CI/CD or filter them out of their analyses.
I propose that, when we generate system tags, we try to detect whether we are running in a CI/CD environment and add the (inferred) name of the CI/CD provider (e.g. GitHub Actions, CircleCI, TravisCI, etc.) as a tag of the form
ci:<provider>.Each CI/CD platform has certain environment variables that it uses to configure internal processes:
Note that all of them seem to set
CI=true. So at the very least we should use that. We can also use the presence or absence of other environment variables to infer which specific CI provider we are working with.