* Validate input to BadgeFactory.create() (#3875)
* validate input to create()
* remove deprecated properties (#3881)
* remove BadgeFactory class (#3884)
* Template literal templates (#4459)
- Remove use of the doT template library and move to generating SVG output using javascript template literals.
- Drop SVGO and mostly manually implement the optimisations.
- Add a bunch more tests
Co-authored-by: Paul Melnikow <github@paulmelnikow.com>
* drop raster support in package CLI (#4523)
* drop raster support in package CLI
* update docs
* rename gh-badges package to badge-maker
* rename gh-badges dir to badge-maker
* update relative imports and other refs to in parent dir
'gh-badges' --> 'badge-maker'
* update snyk service tests
This change is only tangentially related
We've used the shields repo as an example for these tests so
moving files around in our repo has a knock-on effect on them
* add missing type hints to dev style page
* write the changelog/migration guide for v3
* use extension in README CLI example
* update CLI help
whoops - missed this in #4523
* bump version
* update for self-hosting users
* README updates
* drop .format param from CLI, always output SVG
* Change text[] to label and message, Remove JSON output
- Change text[] to label and message
- Fix message only badge
- Remove JSON output format
- Update the docs
* update package-lock
* rename 'template' to 'style'
* handle invalid styles in coalesceBadge
* ensure makeBadge is passed a string for template in coalesceBadge()
issue #4925
* fix (logo/no label text/label color specified) case
issue #4926
* add example of (logo/no label text/label color specified) to style debug page
* update type defs
* padding fix for FTB style
Co-authored-by: Paul Melnikow <github@paulmelnikow.com>
* Gitpod is no longer in Beta
* Automatically open the web preview on start-up in Gitpod
* Accelerate Gitpod start-up with continuously prebuilt workspaces
* Install Prettier VS Code extension in Gitpod
Fixes https://github.com/badges/shields/issues/3260
Problem happens when a value of a color in an old PNG static badge is a number: http://localhost:8080/my-label/my-message.png?color=1. In this case `color` in `queryParams` is a number.
0a0b5b3f03/core/server/server.js (L203-L212)
Surprisingly service test listed below is passing currently on master - value `1` is represented in `queryParams` as a String (only in test).
`services/static-badge/static-badge.tester.js`
```js
t.create('Old static badge with a number as a color')
.get('/foo/bar.png?color=1', { followRedirect: false })
.expectStatus(301)
.expectHeader('Location', '/badge/foo-bar-1.png')
```
Moreover I added some code + description allowing to debug server.
While working on #2428 I found myself wanting to reload the server frequently. This is working great and reducing my iteration time significantly. I should have tackled this way sooner! 🙊
I’ve left `verbose` on which seems useful, at least in the short term while we’re tuning the configuration.
Close#2426
While Next.js can handle static sites, we've had a few issues with it, notably a performance hit at runtime and some bugginess around routing and SSR. Gatsby being fully intended for high-performance static sites makes it a great technical fit for the Shields frontend. The `createPages()` API should be a really nice way to add a page for each service family, for example.
This migrates the frontend from Next.js to Gatsby. Gatsby is a powerful tool, which has a bit of downside as there's a lot to dig through. Overall I found configuration easier than Next.js. There are a lot of plugins and for the most part they worked out of the box. The documentation is good.
Links are cleaner now: there is no #. This will break old links though perhaps we could add some redirection to help with that. The only one I’m really concerned about `/#/endpoint`. I’m not sure if folks are deep-linking to the category pages.
There are a lot of enhancements we could add, in order to speed up the site even more. In particular we could think about inlining the SVGs rather than making separate requests for each one.
While Gatsby recommends GraphQL, it's not required. To keep things simple and reduce the learning curve, I did not use it here.
Close#1943Fix#2837Fix#2616
Often when responding to bug reports it would be helpful to easily run an example failing badge URL. It takes a while to do that, because you have to copy and paste just the right part of the badge URL. This works on `img.shields.io` links as well as partial paths and should make this really easy. 💨
This removes `LONG_CACHE` and its descendants, which was a feature that added `?maxAge` to the live preview badges in the frontend. Since they are all static that is no longer needed, as the static badges all have longer cache timeouts regardless.
Please join me in welcoming @calebcartwright to the maintainer team!
Caleb has been doing an incredible job rewriting services, among other things, and we're glad to have him on board!
- Stop running daily service tests in the main repo (since they're now handled [over here](https://github.com/badges/daily-tests)
- Add coverage and separate daily tests badges with links to coveralls
- Update our coverage ignores
- Move scripts, which do not need coverage, into `scripts/`
- Split out coverage test for npm package
- Remove spurious env var
Ref: #1584#2314
* move gh-badges files out of /lib
As far as possible, this is just moving files
around and updating paths however there are 2
functional changes in this commit:
- remove use of lib/register-chai-plugins.spec
in badge-cli.spec.js
- remove use of starRating()
in text-measurer.spec.js
* update service tests that use colorscheme.json
* split package.json in two
* clean up import
* don't hard-code path
* start a changelog
* put a license file in the package dir
* re-organise documentation 📚
* don't pack test files
* remove favicon from Makefile
* give package its own test command
* link the docs better in README
* Basic process metrics
* Enable Prometheus by an environment variable
* Code formatting
* Documentation for Prometheus metrics
* Link from README to documentation of Prometheus
* Link from README to documentation of Prometheus
* Link from README to documentation of Prometheus
* Separate module for metrics + tests
* Metrics limited by IP
* Metrics are forbidded for all requets by default
* Code refactoring
* allowedIps passed as a string to PrometheusMetrics
* Handle missing config
* METRICS_PROMETHEUS_ALLOWED_IPS added to documentation
* Log info about enabled metrics
* Unused code removed
* package-lock.json updated
* prom-client updated to 11.1.2
* Code refactoring
* Do not read IP address from X-Forwarder-For header
* define a public interface for NPM package
* move check-node-version to dependencies
* add missing file to package
* update docs
* bump version
* add gh-badges option to issue template
* abstract text measuring from users
* add a DocBlock for BadgeFactory.create()
We’ve cleared the backlog of pull requests needing adoption and closed the old ones out, so it seems best to remove this from the contributing guidelines.
These tests should fail if something is accidentally changed that affects the SVG or JSON files. In the case of deliberate changes, we can update the snapshots.
I don’t like that our build goes red on master all the time due to flaky service tests. I thought I’d look into other CI services that would make it possible to run the scheduled tests nightly without causing those messages to show up.
CircleCI, Heroku CI, and Codeship were obvious choices. Heroku CI wasn’t free and I didn’t have any experience with Codeship, so I looked into CircleCI. I’ve used their 1.0 system a lot though this was my first time on their 2.0 system. As with earlier versions, they’ve put a lot of work into making the build fast – perhaps more than any other CI system I’ve seen.
I had such good results, my goal shifted from scheduled daily builds (that don’t litter our commit history with red builds) to improving the CI experience as a whole.
This change made a big impact:
- Build logs load much, much faster. In the test I just ran, 22 seconds to < 2 seconds, a 90% improvement.
- Status of each step shows up right in the GitHub UI, which makes it much faster to see exactly what’s failed.
- Builds run about 50-75% faster on account of parallelism.
- GitHub service tests are fixed. This has been a long-standing issue.
- Ability to ssh into a build container to debug failures.
Here’s what I did:
- Created custom Docker images with our dependencies. To be honest, I’m not even sure these are necessary, only to install the greenkeeper-lockfile. We could get dejavu from npm. They make startup very fast.
- Created an npm-install stage which loads all dependencies into node_modules and caches them.
- Created separate stages for our main tests, service tests, and frontend tests, and stages to run the main tests and service tests in Node 6. These run in parallel, up to four at a time.
- Separated service test ID output from the service test results themselves. (I check these often during the PR process, when I confirm that service tests actually ran. Because the production Shields server caches the title, after updating it you can’t tell whether the update is taking effect.)
- Added a personal access token for the shields-ci user. This should actually fix the long-standing issue #979. CircleCI provides an option to “Pass secrets to builds from forked pull requests,” which means unlike Travis, they’ll give us enough rope to shoot ourselves in the foot.
- Schedule a daily build, which runs all the service tests.
