Can you maybe test if it fails when updating the woff files but not woff2 as a test? if then the build fails it should work 👍

When you commit woff, but not woff2 the time difference between the two commits should be more than 24 hours and the test should fail.
But you probably won't get that far as without updating the woff2 the browser won't show the changes during development.

I'm not entirely sure why the test didn't fail:
https://travis-ci.org/matomo-org/matomo/jobs/438743756

fyi in case it helps what I'm getting:

$ git log -1 --format='%ad' plugins/Morpheus/fonts/matomo.woff
Wed May 2 07:59:51 2018 +1200
$ git log -1 --format='%ad' plugins/Morpheus/fonts/matomo.woff2
Wed Jul 25 21:54:48 2018 +0200

I don't know if it is supposed to fail right now?
Could echo some information on travis... eg var_dump($woff_last_change);var_dump($woff2_last_change);

Started debugging this on the travis-debug branch, for some reason the date for matomo.woff is the same as the date for matomo.woff2, but only on travis.

Tried getting the remote branch log (git log -1 origin/... ...), but that didn't work on travis either... super strange.

It's not needed to have this in 3.6.1 just fyi

I already gave up on debugging it :)

It is supposed to fail now as they weren't committed at the same time and my plan was then to recommit them afterwards to fix it.
Thanks for confirming that it's not me going crazy 🙂

Maybe travis-ci/travis-ci#7254 (comment) helps?

@tsteur That makes sense. Travis probably does a git clone --max-depth=0 and therefore doesn't know what happened before. But I guess a full clone would be far slower, so I guess this test isn't possible.

👍 shall we close this PR then?

Was hoping getting the log from the origin remote would get around the lack of history, but it didn't...

Unfortunatly

Thought of a way to do the test this way, could use the github API to get the last modified time (using whatever travis environment variable gets the commit hash). Probably wouldn't work on PRs, but doesn't really have to. @Findus23 would you have time for this? Found an example request here: https://stackoverflow.com/questions/50194241/get-when-the-file-was-last-updated-from-a-github-repository

Made the change to use the github API and ran into another problem, rate limiting due to travis-ci usage. Need to create a bare oauth token and use as a secure travis env variable if want to continue down this path.

cc @tsteur / @mattab

Need to create a bare oauth token and use as a secure travis env variable if want to continue down this path.

@diosmosis Is this the only task left to do? if so I can do this. Can you send the link to the github guide to follow?

@mattab should follow https://help.github.com/en/articles/creating-a-personal-access-token-for-the-command-line and give the token no permissions. Then need to add it as a secure environment variable to travis-ci: https://docs.travis-ci.com/user/environment-variables/#encrypting-environment-variables

@mattab @diosmosis what's the status here? @mattab I suppose you need to do something here?

@tsteur two options:

• Add a github oauth token to travis-ci so we can make API requests to the github API for this one check.
• Or somehow get woff2_compress to be installed on travis-ci.

I don't know if either are high value enough to spend time on.

@diosmosis now that we use chrome for tests, maybe chrome loads the woff2 anyway and this test is not needed anymore?

@tsteur this test is to make sure the woff2 file is up to date, since it has to be generated manually after every change to the icon font file. So we need to run woff2_compress in travis and compare w/ the file or some other way to make sure we know it is up to date. I guess it's not super important if we don't have this test, but I suspect someone will forget w/o the check.

Or do you mean because chrome will try to use woff2 first? If so, I guess we don't need this then...

Or do you mean because chrome will try to use woff2 first? If so, I guess we don't need this then...

That's what I meant. We're mentioning it also first in the font so likely this should be the case.

Ok, I'll close this then. No issue for me if someone wants to re-open and finish this, but it doesn't seem necessary anymore.