Continue to implement #2698:
- Add `core/base-service/index.js` (but hold off on moving the things it imports)
- Add shortcuts in `services/index.js` for Base*Service, errors, and deprecatedService. This file will be streamlined later to avoid cluttering it with rarely used bits.
- Apply consistent ordering of imports and use of `module.exports` in testers.
- Remove some renaming of imports.
- Remove obsolete tests here and there.
* don't use a libraries.io token for bower integration
The libraries.io docs claim you need to be authenticated
to make any API request: https://libraries.io/api#authentication
In practice we can call https://libraries.io/api/bower/jquery
just fine with no token and based on chucking a load of
requests at it and examining the `x-ratelimit-remaining`
headers you actually seem to get a better limit with no
authentication.
All of our libraries.io badges in `services/librariesio`
seem to have been running fine with no token for some time.
* change jira auth settings to jira_user, jira_pass
All the other services use servicename_user, servicename_pass
This switches JIRA to use that convention by preference
but supports _username and _password for legacy users.
* add docs for server secrets
* add danger rule for server-secrets.md
this rule prompts users to update server-secrets.md
if 'serverSecrets' is in the diff
- The goal of this PR is:
- Consume the new service-definition format. (#2397)
- Make the frontend more readable.
- Behavior changes:
- I changed the **Image** field in the markup modal to show only the path.
- I added another click-to-select field below that shows the complete URL.
- This made it easier to suppress the live badge preview while it contains placeholders like `:user` or `:gem`, a minor tweak discussed at https://github.com/badges/shields/issues/2427#issuecomment-442972100.
- The search box now searches all categories, regardless of the current page. (This is an improvement, I would say.)
- I did not deliberately address performance, though I ripped out a bunch of anonymous functions and avoided re-filtering all the examples by category on every render, which I expect will not hurt. I haven't really tested this on a mobile connection and it'd be worth doing that.
- It would be great to have some tests of the components, though getting started with that seemed like a big project and I did not want to make this any larger than it already is.
It's a medium-sized refactor:
1. Replace `BadgeExamples`, `Category` and `Badge` component with a completely rewritten `BadgeExamples` component which renders a table of badges, and `CategoryHeading` and `CategoryHeadings` components.
2. Refactor `ExamplesPage` and `SearchResults` components into a new `Main` component.
3. Rewrite the data flow for `MarkupModal`. Rather than rely on unmounting and remounting the component to copy the badge URL into state, employ the `getDerivedStateFromProps` lifecycle method.
4. Remove `prepareExamples` and `all-badge-examples`.
5. Rewrite the `$suggest` schema to harmonize with the service definition format. It's not backward-compatible which means at deploy time there probably will be 10–20 minutes of downtime on that feature, between the first server deploy and the final gh-pages deploy. 🤷♂️ (We could leave the old version in place if it seems worth it.)
6. Added two new functions in `make-badge-url` with tests. I removed _most_ of the uses of the old functions, but there are some in parts of the frontend I didn't touch like the static and dynamic badge generators, and again I didn't want to make this any larger than it already is.
7. Fix a couple bugs in the service-definition export.
* TUTORIAL.md: Mention URL mapping upfront and clarify static meaning
* Be more specific that route is URL
* Explain async without reference to prior knowledge
* Use the same example URL to explain the directory layout
* Clean diff
* `route()` + `static`
- The route includes the base URL, so try to clarify that
- Add some more information about `static`
This continues the work from #2279, by allowing example badges to be specified using `namedParams`. Using an object makes it possible for us to display these in form fields down the line. (#701)
I've called this the "preferred" way, and labeled the other ways deprecated. I've also added some doc to the `examples` property in BaseService. Then I realized we had some doc in the tutorial, though I think it's fine to have a short version in the tutorial, and the gory detail in BaseService.
I've also added a `pattern` keyword, and made `urlPattern` an alias.
Closes#2050.
The term “url” is overloaded in services, to refer to the Shields route and also the API URL. Calling the Shields URL a “route” is on the whole more descriptive, and makes it clearer and more obvious which one of these we’re talking about. It’s a small thing, though seems like an improvement.
We have a few functions called `buildUrl`. I’ve renamed them to `buildRoute` when they refer to routes, and left them as `buildUrl` when they refer to API URLs.
I included a minor style tweak and some formatting cleanup in `TUTORIAL.md`.
This continues a consistency update we’ve been making to standardize on URL based on a recommendation from WHATWG: https://url.spec.whatwg.org/#goals
This also helps with copying and pasting between all-badge-examples and new-style services, where it’s otherwise easy to make a mistake.
Ref: #1322#1341
* The most recent code examples in tutorial
* An extra empty line removed
* An extra escapring characters removed
* checkErrorResponse mentioned in tutorial
* Typo fix in tutorial
* Static badges as examples in tutorial
* Missing word in the tutorial added
* Typo fix in tutorial
- 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
- `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.
- 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
- 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).
