Describe the bug
The CI environment variable is not set in GitHub Actions. A lot of software relies on that to detect whether it's running in CI.
Example: https://github.com/jruby/jruby/issues/6113#issuecomment-596196601
Area for Triage:
Question, Bug, or Feature?:
Feature
Virtual environments affected
Expected behavior
The environment variable CI should be set to true, as it is in most CI solutions out there (e.g., TravisCI).
Actual behavior
It's not set: https://github.com/ruby/setup-ruby/runs/493307400?check_suite_focus=true
Hello, @eregon
I have prepared https://github.com/actions/virtual-environments/pull/530 PR to the CI variable.
@al-cheb , I have a concern. I am not sure that this variable should be really set during image-generation. What if customer builds his own vhd based on our source code, and run it locally? In this case, this variable will be set but actually, it won't real CI.
In my opinion, this environment variable should be set by actions/runner on build queue.
@al-cheb , @alepauly , any thoughts?
In my opinion, this environment variable should be set by actions/runner on build queue.
@al-cheb , @alepauly , any thoughts?
@maxim-lobanov I agree. Transferring to actions/runner where if fixed then it will work for self-hosted runners as well.
@maxim-lobanov we have set GITHUB_ACTIONS=true for this.
https://help.github.com/en/actions/configuring-and-managing-workflows/using-environment-variables#default-environment-variables
I think CI is a fairly standard environment variable to be set in CIs. Requiring GITHUB_ACTIONS means it's quite verbose in the code and not portable.
GitHub action is not only a CI system, the workflow run can be triggered on any GitHub event, like Issue create/comment, so I am not sure setting CI=true is appropriate for those scenarios. 馃槃
@chrispat to comment on this.
You can set environment variables at the workflow level so it's easy to add this where needed.
on: pull_request
env:
CI: true
jobs:
do-things:
We could even include this in our starter workflows that are more CI oriented.
talked to @chrispat and we agree that making this easier is the right thing to do since this seems to reduce the friction.
I agree it's easy enough to set it, and starter workflows can help there.
However it's still a potential gotcha when migrating to GitHub Actions which doesn't sounds worth the effort debugging, when I think almost all other CI solutions set it.
I understand GitHub Actions is not just a CI solution, but I'd argue any code running in GitHub Actions is meant to be run "unattended, automated, CI-like" and so I doubt it would hurt to set it.
That said, I don't see a lot of agreement here so I'll close this issue.
I missed the link above, it looks like it's actually been implemented :smiley: https://github.com/actions/runner/pull/374
shipped as part of the 2.168.0 runner.
Most helpful comment
GitHub action is not only a CI system, the workflow run can be triggered on any GitHub event, like Issue create/comment, so I am not sure setting
CI=trueis appropriate for those scenarios. 馃槃@chrispat to comment on this.