Travis deploy steps have to be a script file (not a list of steps).
Revert 3ec009e6 because “npm install git+file” actually reads from the local master branch, which
- doesn’t work on Travis since Travis checks out a detached head
- doesn’t work as expected locally, since you might have local changes or might be working from a different branch
For the time being it’s easier to simplify the Docker script and release a known published version.
The previous method only worked locally inside the repo, but not once the package is published to npm.
Once published, built-in themes are flattened instead of nested.
- This component was not published to the rpm registry anyway
- We depended on the repo’s master branch which can break things for everyone
- Its repo was not getting much attention which meant
* no tests, no coverage report
* no linting
* no package linting (e.g. had 2 dependencies that weren’t actually used)
It will be simpler to manage this way
If a theme has a build process, it will likely publish a subfolder (e.g. “dist”) to npm.
It can simply set “thumbsup.themeRoot” in its package.json so thumbsup looks in the right place.
Some benefits:
- no need to check-in a full website to compare against
- targeted asserts, instead of a “should be 100% the same”
- more robust against cosmetic theme changes
- allows for testing more edge cases in the future
- can’t forget to run the integration tests since they’re part of “npm test”
fix(index): Continue on errors during find
This ensures the gallery is created even when some files are
inaccessible (for example due to invalid names or file permissions).
Requires running the test in Docker as non-root to allow file access test
Thumbsup used to stop at the first problem processing a file.
This was a problem on large galleries where you’d need to run it again and again, fixing files as you went.
This change:
- skips problematic files and shows a summary at the end
- logs all warnings/errors to <thumbsup.log> when running the default output
Also refactor and cleanup of the logging logic.
GraphicsMagick can’t process animated GIFs well unless all frames are coalesced, which creates very large files.
This means there is a new dependency on Gifsicle which is very good at working with animated GIFs.
- Thumbnails are still processed through GraphicsMagick (more options, e.g. centre-crop)
- Large previews of animated GIFs go through Gifsicle
The startup checks are updated to check for the Gifsicle binary.
Fixes#96.
