It can be helpful to have some diagnostic pages for development and quality control. I added one here for the logos, which renders all the named logos in ?style=flat and ?style=social.
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
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.
This implements the configuration mechanism I described in #2621. The heavy lifting is delegated to [node-config](https://github.com/lorenwest/node-config) with a minor assist from [dotenv](https://github.com/motdotla/dotenv).
`private/secret.json` has been replaced with environment variables and/or `config/local.yml`. See `doc/server-secrets.md`.
* 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
To run this requires renaming `private/secret.json` to `private/secret-production.json` in the working tree used for deployment.
Goals:
- Ensure production secrets are not used in development
- Avoid modifying the current working tree
- Avoid branch switching: make sure the current ref gets deployed
- If something other than `master` is deployed, leave `HEAD` alone; don't reset to `master`
- Ensure the build runs before server deploy (#1941)
This makes use of Git working trees, which is a relatively new but stable feature in Git. I was initially reluctant to use git worktree, mostly because I don't like adding new tooling that isn't necessary. The other alternative I experimented with was copying or re-cloning to an entirely separate working copy. This was messier and more brittle than using `git worktree`.
This is a fairly simple addition of a Redis-backed TokenPersistence. When GithubConstellation is initialized, it will create a FsTokenPersistence or a RedisTokenPersistence based on configuration. Have added tests of the Redis backend as an integration test, and ensured the server starts up correctly when a `REDIS_URL` is configured.
Ref: #1848
This addresses some long-standing comments in https://github.com/badges/shields/issues/1458#issuecomment-368270996
We should also adopt Gatsby, create-react-app, or something similar designed for static sites, to eliminate the unnecessary runtime dependency on Next.js while also letting someone else maintain our front-end tooling. :-D These alternative tools might work just fine in subdirectories without config, and we might be able to leave Jekyll turned on (though we don’t need it). However these git-related changes are orthogonal.
- Don’t check out master, making it possible to deploy the currently checked-out commit
- Disable Jekyll which we don’t need. This allows _next folders to be deployed, and the related URL rewriting to be removed.
- Completely empty the deploy branch’s index before deployment. This prevents errors from broken symlinks, while preserving the commit history in the deploy branch.
- Do the deployment work in a git working tree. This requires Git 2.18 but makes it possible to do the above very safely.
- 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
* 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
- 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
The quoting style chnaged in b411f08.
This is to fix the production build, in which image links were all broken because they pointed to shields.io instead of img.shields.io.
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.
- Build index.html at deploy time
- Update corresponding documentation references
- Since index.html is untracked, git add needs -f
- Clarify gh-pages generated commit message
- Improve Makefile dependencies related to website generation
As discussed in #936, tracking the index.html causes makes PRs longer / noisier
and causes extra merge conflicts. More importantly, it causes contributors to
inadvertently edit the wrong file, which causes extra work (#949) or
contributions to be lost (#898).
Since there's no need for index.html in development (everything uses try.html) a
logical solution is to generate and commit the index.html at deploy time.
Recording compiled or generated files in a deploy commit is a reasonable
practice for git-based deploys (Heroku, gh-pages, and others).
The old version of this was slightly "unsafe" for my taste, in that it depended
on the local copy of gh-pages (if it existed) and master. The new version just
replaces gh-pages with master + the new commit.
Closes#936.
Fixes#954 (the PR).
