* Add dynamic yaml badge
* Forgot package lock
* Switch tests to yaml data source
* Add yaml to the dynamic badge maker options
* Reorder to match documentation examples
* Reordered dynamic types to be alphabetical
* Removed regex as pinend commit makes it unnecessary and fixed url
* Removed unused import
* Add more YAML MIME types
* Removed duplicate tests which don't differ between data types
Make a clear distinction between programmer errors ("internal errors") and runtime errors, and allow configuring the server to let the programmer errors bubble up in development and unit testing. This saves a huge amount of time because it generates ordinary stack traces when things go wrong. And, if these errors occur in production, we'll catch them, and display **shields | internal error** which is the equivalent of a 500 error.
Instead of centralizing examples, specify them from within a service.
* Avoid duplication in service loading + refactor
* Avoid duplication in URLs, rename uri -> url in BaseService
This merges the `node-8` branch. The heavy lift was by @Daniel15 with refactoring from me and a patch by @RedSparr0w.
* New API for registering services (#963)
* Disable Node 6 tests on node-8 branch (#1423)
* BaseService: Factor out methods _regex and _namedParamsForMatch (#1425)
- Adjust test grouping
- Rename data -> queryParams, text -> message
* BaseService tests: Use Chai (#1450)
* BaseService: make serviceData and badgeData explicit and declarative (#1451)
* fix isValidStyle test (#1544)
* Run tests in Node 9, not Node 6 (#1543)
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.
* add dynamic xml badge support
* add tests
* dynamic badge add tests for query param
* remove try catch
* use `checkErrorResponse()`
* update tests
* [dynamic json] add test for multiple items
* Rebase, [dynamic xml] Add support for multiple items
* 404 response -> resource not found
* multiple results test less greedy regex
still alot of room for improvement to this test
* update dynamic badge gen
* add dynamic xml gen tests
* update tests id & path
* datalist -> select
* uri -> url
kept support for uri, incase of any already existing badges.
* split dynamic gen uri
* update query placeholder
Ref: #1379
This takes a naive approach to font-width computation, the most compute-intensive part of rendering badges.
1. Add the widths of the individual characters.
- These widths are measured on startup using PDFKit.
2. For each character pair, add a kerning adjustment
- The difference between the width of each character pair, and the sum of the characters' separate widths.
- These are computed for each character pair on startup using PDFKit.
3. For a string with characters outside the printable ASCII character set, fall back to PDFKit.
This branch averaged 0.041 ms in `makeBadge`, compared to 0.144 ms on master, a speedup of 73%. That was on a test of 10,000 consecutive requests (using the `benchmark-performance.sh` script, now checked in).
The speedup applies to badges containing exclusively printable ASCII characters. It wouldn't be as dramatic on non-ASCII text. Though, we could add some frequently used non-ASCII characters to the cached set.
IcedFrisby/IcedFrisby#71 will allow us to set a per-test `timeout()` and per-test `retry()`, which should allow us to keep flaky tests green most of the time.
A slough of service tests are failing locally, though they are also failing in master and seem unrelated to these changes. (#1359)
IcedFrisby is maturing toward a 2.0 API. There's been one breaking change to the way dependencies are installed, and probably more changes to come in the API itself. Shields uses such a small part of that API that 2.0, when it's released, may not even affect us.
… so we can stop saying "you forgot to…" in code review. 😀
This idea has come up a number of times. If we can write code to detect a contributor guideline, this tool will message the contributor automatically in a pull request. This lets people fix their own problems, relieves maintainers and reviewers from nagging, and keeps anyone from having to constantly ask for more tests.
For futher reading:
- [How to use Danger well](http://danger.systems/js/usage/culture.html)
- [Examples of the kind of thing it can do](http://danger.systems/js/)
- [Dangerfile reference](http://danger.systems/js/reference.html)
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.
- Fix issue in Firefox 57 when run from static build
- Fix color parameter in dynamic badge maker
- Correctly apply maxAge in usage badges
- Follow the WHATWG lead and begin to standardize on URL, not URI (https://url.spec.whatwg.org/#goals)
Both of the depcheck's are throwing errors
OS: `Windows 10`
Node: `v8.7.0`
Current Output:
```cmd
npm run frontend-depcheck
> gh-badges@1.3.0 frontend-depcheck C:\Users\Dan\Documents\GitHub\shields
> check-node-version --node '>= 8.0'
C:\Users\Dan\Documents\GitHub\shields\node_modules\semver\semver.js:678
throw new TypeError('Invalid comparator: ' + comp);
^
TypeError: Invalid comparator: '
at Comparator.parse (C:\Users\Dan\Documents\GitHub\shields\node_modules\semver\semver.js:678:11)
at new Comparator (C:\Users\Dan\Documents\GitHub\shields\node_modules\semver\semver.js:662:8)
at C:\Users\Dan\Documents\GitHub\shields\node_modules\semver\semver.js:828:12
at Array.map (<anonymous>)
at Range.parseRange (C:\Users\Dan\Documents\GitHub\shields\node_modules\semver\semver.js:827:13)
at Range.<anonymous> (C:\Users\Dan\Documents\GitHub\shields\node_modules\semver\semver.js:769:17)
at Array.map (<anonymous>)
at new Range (C:\Users\Dan\Documents\GitHub\shields\node_modules\semver\semver.js:768:40)
at C:\Users\Dan\Documents\GitHub\shields\node_modules\check-node-version\index.js:119:32
at module.exports (C:\Users\Dan\Documents\GitHub\shields\node_modules\map-values\index.js:9:18)
npm ERR! Windows_NT 10.0.16299
npm ERR! argv "C:\\Program Files\\nodejs\\node.exe" "C:\\Users\\Dan\\AppData\\Roaming\\npm\\node_modules\\npm\\bin\\npm-cli.js" "run" "frontend-depcheck"
npm ERR! node v8.7.0
npm ERR! npm v4.3.0
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! gh-badges@1.3.0 frontend-depcheck: `check-node-version --node '>= 8.0'`
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the gh-badges@1.3.0 frontend-depcheck script 'check-node-version --node '>= 8.0''.
npm ERR! Make sure you have the latest version of node.js and npm installed.
npm ERR! If you do, this is most likely a problem with the gh-badges package,
npm ERR! not with npm itself.
npm ERR! Tell the author that this fails on your system:
npm ERR! check-node-version --node '>= 8.0'
npm ERR! You can get information on how to open an issue for this project with:
npm ERR! npm bugs gh-badges
npm ERR! Or if that isn't available, you can get their info via:
npm ERR! npm owner ls gh-badges
npm ERR! There is likely additional logging output above.
npm ERR! Please include the following file with any support request:
npm ERR! C:\Users\Dan\AppData\Roaming\npm-cache\_logs\2017-12-04T00_30_04_974Z-debug.log
```
```cmd
npm run server-depcheck
> gh-badges@1.3.0 server-depcheck C:\Users\Dan\Documents\GitHub\shields
> check-node-version --node '>= 6.0 < 9.0'
The system cannot find the file specified.
npm ERR! Windows_NT 10.0.16299
npm ERR! argv "C:\\Program Files\\nodejs\\node.exe" "C:\\Users\\Dan\\AppData\\Roaming\\npm\\node_modules\\npm\\bin\\npm-cli.js" "run" "server-depcheck"
npm ERR! node v8.7.0
npm ERR! npm v4.3.0
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! gh-badges@1.3.0 server-depcheck: `check-node-version --node '>= 6.0 < 9.0'`
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the gh-badges@1.3.0 server-depcheck script 'check-node-version --node '>= 6.0 < 9.0''.
npm ERR! Make sure you have the latest version of node.js and npm installed.
npm ERR! If you do, this is most likely a problem with the gh-badges package,
npm ERR! not with npm itself.
npm ERR! Tell the author that this fails on your system:
npm ERR! check-node-version --node '>= 6.0 < 9.0'
npm ERR! You can get information on how to open an issue for this project with:
npm ERR! npm bugs gh-badges
npm ERR! Or if that isn't available, you can get their info via:
npm ERR! npm owner ls gh-badges
npm ERR! There is likely additional logging output above.
npm ERR! Please include the following file with any support request:
npm ERR! C:\Users\Dan\AppData\Roaming\npm-cache\_logs\2017-12-04T00_32_13_243Z-debug.log
```
Looks like its due to `'` being used around the version rather than `"`.
This PR Output:
```cmd
npm run frontend-depcheck
> gh-badges@1.3.0 frontend-depcheck C:\Users\Dan\Documents\GitHub\shields
> check-node-version --node ">= 8.0"
```
```cmd
npm run server-depcheck
> gh-badges@1.3.0 server-depcheck C:\Users\Dan\Documents\GitHub\shields
> check-node-version --node ">= 6.0 < 9.0"
```
