Skip to content

Latest commit

 

History

History
 
 

.circleci

Folders and files

NameName
Last commit message
Last commit date

parent directory

..
scripts
scripts
 
 
README.md
README.md
 
 
config.yml
config.yml
 
 

README.md

Vanilla CircleCI setup.

Overview

Custom checkout script

We have a custom checkout script that does a few thing better than the built in one.

  • Provides an ENV var $CUSTOM_TARGET_BRANCH (gives target branch for a PR as proposed in CCI-I-894).
  • Does not screw up the reference to master branch (a la #23781 and 24975
  • Attempts to merge the target branch into the current branch and runs all tests against that as proposed in CCI-I-431

Inline Orbs

Currently the vanilla/checkout orb is declared inline. This along with much of the content of aliases: could be made into properly published orbs.

Required Github access token

Running this requires a configured github access token with permission to fetch repo info set in the environmental variable $GITHUB_TOKEN.

WARNING: Be sure to provide a token with the minimum required permissions & make sure it is set securely through the circleci env vars or a context

Workflows

The current workflows branch like this:

frontend_setup -> frontend_test
                  frontend_build
                  frontend_lint
                  frontend_typecheck
php_setup      -> php_72_tests
                  php_72_integration
                  php_71_tests (nightly only)
                  php_71_integration (nightly only)
                  php_73_tests (nightly only)
                  php_73_integration (nightly only)
php_72_lint
php_71_lint (nightly only)
php_73_lint (nightly only)
dependency_audit (nightly only)

Some checks only run in nighly builds (See the nightly workflow vs the commit workflow).

Tips & Tricks

  • It is highly recommend to grab the circleci CLI. This can be used to validate/expand configs, and run single jobs locally.
  • Workspace attachment is the preferable way to pass data between different parts of workflows. It is very fast. Using the cache commands requires zipping/unzipping/validating all contents, sending that to S3, and downloading it back which is SLOW with a lot of directories (eg. node_modules). Be careful with how the caching is used if added, because it can actually slow down builds significantly. See Caching, Artificats, and Workspaces.

Good general resources