- Periodically log github auth information
- Tokens are hashed which reduces the security risk inherent in the logs
- A consistent hash is used so tokens can be correlated across the three data structures and across the three servers
- Add an admin endpoint for github auth information
- Tokens are returned as-is to enable troubleshooting (e.g. comparing our reqRemaining to github’s)
While working on #1288 I configured frontend tests. I'm going in a different direction with that, though it seems worth keeping the test configuration. I added tests for one of the helper methods.
- Heroku reads the Node version from package.json. We're about to upgrade to Node 8 so this change to `engines` is only pre-emptive. It won't have any effect on the production servers.
- The production deploy scripts were missing the frontend files. This fixes that.
- This modifies the build setup to allow `BASE_URL=/`, which makes all requests relative to the page itself. That simplifies deploying the "debugging" frontend to the production servers, and makes it easy to host the frontend on Heroku.
I rewrote the frontend in React using a module bundler. It's matched feature-for-feature with the current frontend, with only slight changes in the styling. I did not fuss about making the styling identical; the badge popup looks particularly different.
This makes the front end much easier to develop. I'm really looking forward to implementing #701, to which this paves the way.
This makes light use of Next.js, which provides webpack config and dev/build tooling. We’ll probably replace it with create-react-app or our own webpack setup because unfortunately it comes with a lot of runtime overhead (the build is 400k).
Let’s open new issues for bugs and features, and track other follow-ups here: https://github.com/badges/shields/projects/1
The version in Shields goes back to last August. I reviewed the commits and didn't see any obvious incompatibilities. Hopefully @espadrine can weigh in!
Sazerac is a library for data-driven tests, where a series of tests asserts that the return value of a function matches the expected value. It provides nice syntax for tightening this up.
https://hackernoon.com/sazerac-data-driven-testing-for-javascript-e3408ac29d8c
This converts our tests to use it, and replaces some similar home-grown code.
I fixed one bug I encountered along the way: mikec/sazerac#12.
* Push frontend to production servers at /index.html
Local production builds will use local server instead of img.shields.io, to support local testing
* Restore https://img.shields.io to example URIs
* Add User Defined URL support
* Add test
* eslint fixes
* 100% coverage
* use JSONpath
* update try.html
* Update tests, restore prefix & suffix
* order dependencies alphabetically
* update jsonpath version dependency
* update url structure & move to query strings
* update error handling & remove xml refrences
* fix eslint errors
* update tests
* update dynamic badge generator
* url -> uri & decode uri
Allow an encoded url to be used.
needed for any uri that requires params in the address
* resolve conflicts
* update for new page generation
* check uri is defined
* add query params to `request-handler.js`
* eslint fixes
* add test for no uri specified
* move query params to be local to dynamic badge
* update tests
* dynamic badge gen use same base url as static badge
- Followup from #1163
- Retire try.html
- Separate build config for dev and production
- Move config for badge examples into the JS build
- Move the prod transform into npm scripts
- In the future this could be handled using a bundler plugin
- make website builds production build as before
- Run the production build in CI to make sure it’s working
- Build the frontend on Heroku
I developed this for #820 to provide the correct cache behavior when a service wants to use custom parameters from the query string.
For safety, only the declared parameters (and the global parameters) are provided to the service. Consequently, failure to declare a parameter results in the parameter not working at all (undesirable, but easy to debug) rather than indeterminate behavior that depends on the cache state (undesirable, but hard to debug).
This pull request sets us up to generate the badge examples dynamically from data and code.
Right now, try.html is still checked in, mostly for the benefit of reading this diff, though it should be removed on the next pass to avoid unnecessary complexity at merge time.
- Add tests to request-handler to prepare for some tweaks to caching for #820
- Clean up code in request-handler: renames, DRY, arrows, imports
- Allow for clean shutdown of `setInterval` code. This requires the ability to cancel autosaving.
- Upgrade to Mocha 4, and clean up so the process exits on its own (see mochajs/mocha#3044)
- Better encapsulate analytics
- `make setup` (i.e. `make`) in the dev tutorial seems an unnecessary step. Badges will load from my local server after a clone, as long as I open try.html.
This adds badges for Github issues and pull requests. You can display the state, title, username, number of comments, age, time since last update, and state of checks.
Provides an endpoint the Shields CI can use to fetch PR titles for #979 and resolves#1011.
The intended behavior of the bracketed [github], [bower], [discord] service names in the pull request title is to trigger the designated service tests. That way, affected services can be proven working during code review, without needing to run tests on a dev machine, nor running all the slow (and flaky) service tests.
Example pull request titles:
- [Travis] Fix timeout issues
- [Travis Sonar] Support user token authentication
- [CRAN CPAN CTAN] Add test coverage
The observed behavior is that, whenever bracketed service names are provided, all of the service tests run.
This is due to a Mocha limitation, which is that exclusive tests (it.only and describe.only) can only be applied synchronously. In other words, if we try to fetch the PR title and then add exclusive tests in the callback, all the tests will run anyway. This is true even when using _mocha --delay, as we are, and is true whether I use request or node-fetch.
Undoubtedly this could be fixed, though it's not worth it. The problem is obscure and therefore low priority for Mocha, which is quite backlogged.
And, there is an easy workaround, which is to generate the list of services to test in a separate process.
The pull request script test:services:pr is now split into two parts. First the :prepare script infers the pull request context, fetches the PR title, and writes the list of affected services to a file. Then the :run script reads the list of affected services and runs the appropriate tests.
In addition to sidestepping the Mocha bug, this setup makes it easier to reason about and debug these two steps of the test runner on a dev machine, and since I can't get pipefail to work – and want to be able to run the steps separately – I'm not using Node's built in pre scripts.
Overall, separating these concerns this makes the test runner easier to reason about.
Reorg of the tests: move them just alongside their code. The principle relates to grouping by coupling, not by function and is established in best-practice documents (e.g. https://github.com/focusaurus/express_code_structure#underlying-principles-and-motivations), despite its break from the tradition of a separate `test/` tree. All of today's tools can handle tests spread through the repository.
There are some good, if subtle consequences of this change:
- Since files are close at hand, friction is reduced at development time, which encourages that new tests are written to cover new behaviors.
- It's easier to find the tests that cover a particular piece of functionality.
- It's easier to see which code has tests and which doesn't.
- Eliminate manual testing which is error-prone and time consuming, and must be repeated many times through the PR review process
- Make contributing more fun. For many, fixing bugs and making new badges is faster and more satisfying with automated tests than with manual testing.
- Push out the work of testing new badges to a much broader net. The PR originator could write tests, but so could any other contributor who wants to push review along.
- Detect badge failures resulting from changes in vendor contracts without waiting for user reports.
- Detect and prevent regressions in the code.
- Be runnable, readable, writable, and editable by as many developers as possible, including those who may not be familiar with JavaScript test tools.
-- @paulmelnikow, @niccokunzmann, @Daniel15
Given the chunks coming from imagemagick are getting stored memory and
then tucked into a cache, this function could as easily return a buffer
via callback. Streaming is just making it more complex. (And trickier to
test!)
