env-ci
env-ci copied to clipboard
Github Action incorrect behavior
Bug
Github actions run from a PR do not have the correct env information.
run env-ci in a github action. The PR number is not present
this library uses GITHUB_EVENT_NAME https://github.com/pvdlg/env-ci/blob/master/services/github.js#L27 to check if it is a PR.
Their docs say that GITHUB_EVENT_NAME is set to pull_request when:
Triggered when a pull request is assigned, unassigned, labeled, unlabeled, opened, edited, closed, reopened, synchronize, ready_for_review, locked, unlocked or when a pull request review is requested or removed. See below to learn how this event works with forked repositories.
This variable in my action is set to push.
Environment:
- CI: Github
- Build link: https://github.com/hipstersmoothie/eslint-formatter-github/pull/2/checks?check_run_id=196267212
How should we correctly verify if we are running on a PR?
Not sure if there's any other way to detect without using the pull_request event. However even with that there are still some errors parsing the CI env.
{
isCi: true,
name: "GitHub Actions",
service: "github",
commit: "0e16c49d52f276979dd47d0ff11d2e2f9cc2df65",
isPr: true,
branch: "master",
prBranch: "refs/pull/1/merge",
slug: "iamogbz/github-test",
root: "/home/runner/work/github-test/github-test",
pr: 1,
}
Build: https://github.com/iamogbz/github-test/pull/1/checks
- The
prBranchis wrong
GITHUB_REF=refs/pull/1/merge
https://github.com/pvdlg/env-ci/blob/73299d7f729971a2725cff8b582367f108cfb5ea/services/github.js#L27
- The detection uses the wrong env var
GITHUB_ACTIONS=true
GITHUB_ACTION=run1
https://github.com/pvdlg/env-ci/blob/73299d7f729971a2725cff8b582367f108cfb5ea/services/github.js#L23
- Does not utilize github run ids
GITHUB_RUN_ID=90747655
GITHUB_RUN_NUMBER=6
- Tags can be gotten from
- push event
event.ref(branch or tag) https://developer.github.com/v3/activity/events/types/#pushevent - release event
event.release.tag_namehttps://developer.github.com/v3/activity/events/types/#releaseevent
We just adopted env-ci into @semantic-release. Is this problem still relevant with the latest version?