-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Move [StaticBadge] to own service & add test; also affects [gitter] #2284
Conversation
Co-Authored-By: paulmelnikow <[email protected]>
# Conflicts: # server.js # services/base.js
Generated by 🚫 dangerJS |
maxAge = parseInt(handlerOptions.cacheLength) | ||
// If we've set a more specific cache length for this badge (or category), | ||
// use that instead of env.BADGE_MAX_AGE_SECONDS. | ||
maxAge = handlerOptions.cacheLength |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Technically unrelated, as in the current implementation the static badge does not call this function.
There's no need for parseInt
since we're passing numbers, not strings.
const { makeSend } = require('../lib/result-sender') | ||
const BaseService = require('./base') | ||
|
||
const serverStartTime = new Date(new Date().toGMTString()) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There's no point in passing this down from server.js
.
@@ -214,6 +219,52 @@ class BaseService { | |||
return result | |||
} | |||
|
|||
_handleError(error) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Extract into a method so BaseStaticService
can invoke it from overridden register()
.
overrideLabel || serviceLabel || defaultLabel || this.category, | ||
serviceMessage || 'n/a', | ||
coalesce(overrideLabel, serviceLabel, defaultLabel, this.category), | ||
coalesce(serviceMessage, 'n/a'), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is covered by the static badge tests @RedSparr0w wrote.
@@ -318,28 +327,26 @@ class BaseService { | |||
} | |||
|
|||
static register({ camp, handleRequest, githubApiProvider }, serviceConfig) { | |||
const ServiceClass = this // In a static context, "this" is the class. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some references use this
and some use ServiceClass
. Don't really care which we use, though consistent = better.
ask.res.statusCode = 304 | ||
ask.res.end() | ||
return | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Currently this behavior is not tested.
|
||
const cacheDuration = 3600 * 24 * 1 // 1 day. | ||
ask.res.setHeader('Cache-Control', `max-age=${cacheDuration}`) | ||
ask.res.setHeader('Last-Modified', serverStartTime.toGMTString()) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Currently this behavior is not tested.
I just realised this breaks the "no label" case e.g:
|
Good catch! |
This regression from #2284 was causing `{ message: 22 }` to render as `’n/a’`, as in this test run: https://circleci.com/gh/badges/shields/23680
This regression from #2284 was causing `{ message: 22 }` to render as `’n/a’`, as in this test run: https://circleci.com/gh/badges/shields/23680
Now that the static badge has been moved in #2284, next in line for cleaning out `server.js` is this “static badge, old format.” I imagine this route is _very, very old_. (Actually I wouldn’t be surprised if it’s not used at all. I’d be cuious to see some stats on that endpoint.) In the case of URLs which have permanently changed, an approach I’d like to try is issuing a 301 Redirect. The benefit is that if a user pastes the URL into the address bar while they are previewing or editing it, the browser will replace the address with the corrected URL when it loads. I figure this will cause some people to update their URLs with no effort, simply because they previewed the badge in their browser, and others to change over, if they notice it. We incur a slight cost, which is a second request. However many browsers cache the 301’s indefinitely, and we can set an effectively infinite cache duration so the CDN and most other downstream caches will keep them a long time. And handling the redirect is extremely cheap. This is a nice way to preserve backward compatibility of old routes without having to complicate the new route, such as in the case of vso -> azure-devops. For maintenance purposes, the route that redirects can effectively be treated separately. It’s also a nice, gentle, and confidence-inspiring way to signal that users should update their URLs.
This regression from #2284 was causing `{ message: 22 }` to render as `’n/a’`, as in this test run: https://circleci.com/gh/badges/shields/23680
Now that the static badge has been moved in #2284, next in line for cleaning out `server.js` is this “static badge, old format.” I imagine this route is _very, very old_. (I wouldn’t be surprised if it’s not used at all. I’d be curious to see some stats on that endpoint. If it's not regularly getting requests I could see dropping it.) In the case of URLs which have permanently changed, an approach I’d like to try is issuing a 301 Redirect. The benefit is that if a user pastes the URL into the address bar while they are previewing or editing it, the browser will replace the address with the corrected URL when it loads. I figure this will cause some people to update their URLs with no effort, simply because they previewed the badge in their browser, and others to change over, if they notice it. We incur a slight cost, which is a second request. However many browsers cache the 301’s indefinitely, and we can set an effectively infinite cache duration so the CDN and most other downstream caches will keep them a long time. And handling the redirect is extremely cheap. This is a nice way to preserve backward compatibility of old routes without having to complicate the new route, such as in the case of vso -> azure-devops. For maintenance purposes, the route that redirects can effectively be treated separately. It’s also a nice, gentle, and confidence-inspiring way to signal that users should update their URLs. We could generalize this code, though I think this is a good place to start. This route is tricky because it needs to be loaded last, complicating a reusable solution.
This picks up @RedSparr0w's work in #1802.
async
like the others.