@Findus23 opened this Pull Request on October 8th 2018 Member

related to #12695 and fixes #13210

While @diosmosis' idea of running woff2_compress on travis is probably the best solution, I think checking if both files have been modified at the same time should also work and is much simpler.

The test seems to work locally, but someone should take a look (and afterwards all files need to be updated to fix the test)

@tsteur commented on October 8th 2018 Member

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 👍

@Findus23 commented on October 8th 2018 Member

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.

@Findus23 commented on October 8th 2018 Member

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

@tsteur commented on October 10th 2018 Member

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
@tsteur commented on October 10th 2018 Member

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);

@diosmosis commented on October 10th 2018 Member

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.

@diosmosis commented on October 10th 2018 Member

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

@tsteur commented on October 11th 2018 Member

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

@diosmosis commented on October 11th 2018 Member

I already gave up on debugging it :)

@Findus23 commented on October 11th 2018 Member

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 :slightly_smiling_face:

@tsteur commented on October 11th 2018 Member
@Findus23 commented on October 11th 2018 Member

@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.

@tsteur commented on October 11th 2018 Member

👍 shall we close this PR then?

@diosmosis commented on October 11th 2018 Member

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

@Findus23 commented on October 11th 2018 Member

Unfortunatly

This Pull Request was closed on October 11th 2018
Powered by GitHub Issue Mirror