I am trying to set up Chromatic in Travis.
I saw Chromatic document recommends using this script in Travis
if [[ $TRAVIS_EVENT_TYPE != 'pull_request' || $TRAVIS_PULL_REQUEST_SLUG != $TRAVIS_REPO_SLUG ]];
then
npm run chromatic
fi
with explanation
Travis offers two type of builds for commits on pull requests: so called pr and push builds. It only makes sense to run Chromatic once per PR, so we suggest disabling Chromatic on pr builds for internal PRs (i.e. PRs that aren’t from forks). You should make sure that you have push builds turned on, and add the following code: [[THE CODE ABOVE]]
For external PRs (PRs from forks of your repo), the above code will ensure Chromatic does run on the pr build, because Travis does not trigger push builds in such cases.
Note: We recommend running Chromatic on push builds as pr builds can't always run and fall out of the normal git ancestry. For instance, if you change the base branch of a PR, you may find that you need to re-approve changes as some history may be lost.
Chromatic does work with Travis pr builds however!
Then I read the Travis document about TRAVIS_PULL_REQUEST_SLUG
and TRAVIS_REPO_SLUG
.
TRAVIS_PULL_REQUEST_SLUG:
if the current job is a pull request, the slug (in the form owner_name/repo_name) of the repository from which the PR originated.
if the current job is a push build, this variable is empty ("").
TRAVIS_REPO_SLUG:
- The slug (in form: owner_name/repo_name) of the repository currently being built.
So my understanding is when $TRAVIS_PULL_REQUEST_SLUG != $TRAVIS_REPO_SLUG
, it is a push build, then why it still needs $TRAVIS_EVENT_TYPE != 'pull_request'
?
Is there any difference between them?
Gert from Chroma here.
We recommend to run chromatic only when a build does not originate from a pull request (i.e. a push build), OR when it is a pull request build originating from a fork, in which case the PR slug differs from the repo slug.
Based on the quoted Travis docs, in case of a push build, TRAVIS_PULL_REQUEST_SLUG is empty, in case of a PR build from a fork, it will reference the fork's repo owner. In either case it will be different from TRAVIS_REPO_SLUG. So you're correct that the left-hand side of this condition is superfluous. Feel free to omit it.