Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[TASK] Move the PHP code sniffing to GitHub actions #832

Merged
merged 1 commit into from
Jan 4, 2020

Conversation

oliverklee
Copy link
Contributor

This should speed up the build and reduce our hassle with Travis CI.

Part of #818.

@oliverklee oliverklee added this to the 4.0.0 milestone Jan 3, 2020
@oliverklee oliverklee requested review from zoliszabo and JakeQZ January 3, 2020 12:15
@oliverklee oliverklee self-assigned this Jan 3, 2020
Copy link
Contributor

@JakeQZ JakeQZ left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I found the logs and it seems to be set up correctly. However, I have a couple of queries about the Composer caching step (see review comment).

uses: actions/cache@v1
with:
path: ~/.composer/cache
key: php${{ matrix.php-version }}-composer-${{ hashFiles('**/composer.json') }}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

matrix.php-version seems to be resolving to an empty string, from the logs, e.g. https://github.com/MyIntervals/emogrifier/runs/372326499

Also, an example I found is using composer.lock for the hash rather than composer.json.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This jobs does not use a PHP version matrix. So adding it PHP matrix version to the cache key indeed did not make any sense. (It will do, though, for jobs with a version matrix, e.g., the PHP linting or the unit tests.) Good catch!

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We cannot hash composer.lock because we don't have one, and it gets generated only in the next step (composer install).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have added the explicit PHP version using a matrix now.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll look into the restore-keys to find out what's the difference to key.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seems to be the official way AFAICT.

This should speed up the build and reduce our hassle with Travis CI.

Part of #818.
@oliverklee oliverklee force-pushed the task/actions-sniffer branch from fc28440 to e09c282 Compare January 4, 2020 16:01
@oliverklee
Copy link
Contributor Author

I have repushed.

@JakeQZ
Copy link
Contributor

JakeQZ commented Jan 4, 2020

I have added the explicit PHP version using a matrix now.

I have repushed.

I presume this was a GitHub config change, as I don't spot anything different except that the PHP version now appears in the job commands.

Thinking about this, I'm not sure that the cache key needs to reflect either PHP version or the contents of composer.json - isn't it just the packages that have previously been downloaded, which could be equally useful to multiple PHP versions or composer configurations?

However, I'd be happy to approve this as it is (as you say it seems to be the recommended way), and we can revisit it later if we discover it is posisble to make caching more effective... - let me know what you think.

@oliverklee
Copy link
Contributor Author

I presume this was a GitHub config change, as I don't spot anything different except that the PHP version now appears in the job commands.

I added the PHP version matrix.

Thinking about this, I'm not sure that the cache key needs to reflect either PHP version or the contents of composer.json - isn't it just the packages that have previously been downloaded, which could be equally useful to multiple PHP versions or composer configurations?

I honestly don't know. I've read that some people had problems with the composer cache.

However, I'd be happy to approve this as it is (as you say it seems to be the recommended way), and we can revisit it later if we discover it is posisble to make caching more effective... - let me know what you think.

Yes, please.

Copy link
Contributor

@JakeQZ JakeQZ left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, please.

OK, done :)

@JakeQZ JakeQZ merged commit 2e19e3c into master Jan 4, 2020
@JakeQZ JakeQZ deleted the task/actions-sniffer branch January 4, 2020 19:42
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants