Move the CI from Travis CI to GitHub Actions #208
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,6 +1,6 @@ | ||
| /.gitattributes export-ignore | ||
| /.github/ export-ignore | ||
| /.gitignore export-ignore | ||
| /Doxyfile export-ignore | ||
| /phpunit.xml export-ignore | ||
| /tests export-ignore |
| Original file line number | Diff line number | Diff line change | ||||
|---|---|---|---|---|---|---|
| @@ -0,0 +1,56 @@ | ||||||
| # https://help.github.com/en/categories/automating-your-workflow-with-github-actions | ||||||
|
|
||||||
| on: | ||||||
| pull_request: | ||||||
| push: | ||||||
| schedule: | ||||||
| - cron: '3 3 * * 1' | ||||||
|
|
||||||
| name: CI | ||||||
|
|
||||||
| jobs: | ||||||
| unit-tests: | ||||||
| name: Unit tests | ||||||
|
|
||||||
| runs-on: ubuntu-20.04 | ||||||
|
|
||||||
| strategy: | ||||||
| fail-fast: false | ||||||
| matrix: | ||||||
| php-version: | ||||||
| - 5.3 | ||||||
| - 5.4 | ||||||
| - 5.5 | ||||||
| - 5.6 | ||||||
| - 7.0 | ||||||
| - 7.1 | ||||||
| - 7.2 | ||||||
| - 7.3 | ||||||
| - 7.4 | ||||||
|
|
||||||
| steps: | ||||||
| - name: Checkout | ||||||
| uses: actions/checkout@v2 | ||||||
|
|
||||||
| - name: Install PHP | ||||||
| uses: shivammathur/setup-php@v2 | ||||||
| with: | ||||||
| php-version: ${{ matrix.php-version }} | ||||||
| tools: composer:v2 | ||||||
| coverage: none | ||||||
|
|
||||||
| - name: Cache dependencies installed with composer | ||||||
| uses: actions/cache@v1 | ||||||
| with: | ||||||
| path: ~/.cache/composer | ||||||
| key: php${{ matrix.php-version }}-composer-${{ hashFiles('**/composer.lock') }} | ||||||
| restore-keys: | | ||||||
| php${{ matrix.php-version }}-composer- | ||||||
|
|
||||||
| - name: Install Composer dependencies | ||||||
| run: | | ||||||
| composer update --with-dependencies --no-progress; | ||||||
|
Collaborator
There was a problem hiding this comment. I think we should always install from the lock file for CI builds.
Suggested change
There can be a separate action to update dependencies regularly.
Collaborator
Author
There was a problem hiding this comment. Thanks, I've adapted those two changes. (I have also proposed a PR to get rid of
Collaborator
There was a problem hiding this comment. Ah, I hadn’t yet seen that PR, sorry. Is this recommendation documented anywhere? I would prefer to not break builds just because dependencies have released updated patch versions.
Collaborator
Author
There was a problem hiding this comment. I don't know whether this is documented somewhere. I learned this from a talk on Composer by Nils Adermann (one of the persons behind Packagist). The basic idea is:
Collaborator
Author
There was a problem hiding this comment. I think this change has broken the build. I guess (without being able to spend time on this before later today) that we need different sets of dependency versions for different PHP versions. I'll have a look at this later.
Collaborator
Author
There was a problem hiding this comment. It has turned out that we need to keep using I'll undo this change in a minute, squash and repush.
Collaborator
Author
There was a problem hiding this comment. Done. You can see the build status here on my fork: https://github.com/oliverklee/PHP-CSS-Parser/actions/runs/764969412 (In your repository, the builds will only start after the merge.) |
||||||
| composer show; | ||||||
|
|
||||||
| - name: Run Tests | ||||||
| run: ./vendor/bin/phpunit | ||||||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
AFAIK
should suffice, i.e. we don’t need to re-run the build for other PR actions
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can change this.
Out of curiosity: Are there any other actions? (Closing a PR does not trigger a build AFAIK.)
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There are the following
pull_requestactivity types:But, what I wasn’t aware of, when you don’t specify
typesexplicitly, onlyopened,synchronizeandreopenedtrigger builds so we’d only get rid ofreopenedso I guess you can leave it as-is.(Though I would assume reopened PRs still have their previous builds lying around so I don’t know if there’s a need to actually rebuild but since reopens are relatively rare, it shouldn’t matter).