-
Notifications
You must be signed in to change notification settings - Fork 149
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
Added support for Docker, GitHub Actions and graceful shutdown #677
base: main
Are you sure you want to change the base?
Conversation
b138e28
to
0ad4a76
Compare
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.
Hey, sorry I missed this before leaving a comment on your old PR. Also don't feel offended by me opening #681, those were honestly changes I've had in my own personal fork since June.
My comment here still stands. I'm not particularly attached to 4568
as the default port, it's just what we've always had. Regardless, I really think the Docker image should be consistent with the documented default port.
[![Dependency Status](https://david-dm.org/jamhall/s3rver/status.svg)](https://david-dm.org/jamhall/s3rver) | ||
[![Devdependency Status](https://david-dm.org/jamhall/s3rver/dev-status.svg)](https://david-dm.org/jamhall/s3rver?type=dev) | ||
|
||
S3rver is a lightweight server that responds to **some** of the same calls [Amazon S3](http://docs.aws.amazon.com/AWSJavaScriptSDK/latest/AWS/S3.html) responds to. It is extremely useful for testing S3 in a sandbox environment without actually making calls to Amazon. | ||
|
||
The goal of S3rver is to minimise runtime dependencies and be more of a development tool to test S3 calls in your code rather than a production server looking to duplicate S3 functionality. | ||
The goal of S3rver is to minimize runtime dependencies and be more of a development tool to test S3 calls in your code rather than a production server looking to duplicate S3 functionality. |
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 isn't a typo or a spelling mistake. I'm British, so I use the British English spelling of words! 😃
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.
It makes sense to use the same English spelling conventions throughout the docs, but surely there would be more changes to add too. Consider dropping this change and creating a different PR to address English language spelling conventions.
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.
I'm 100% fine with the Docker stuff, I would approve a PR containing only those changes. However I think GitHub actions were handled in #681, and I am unconvinced about the need for graceful shutdown.
@ad-m Thanks for the initiative you took on this PR. If you can address my concerns in the review I'd be happy to come back to review this PR again.
@@ -0,0 +1,2 @@ | |||
node_modules | |||
.git |
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.
Missing newline
@@ -0,0 +1,26 @@ | |||
name: JavaScript files |
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 looks good but workflows have been addressed in #681.
Current source: https://github.com/jamhall/s3rver/blob/main/.github/workflows/ci.yml
I think the existing ci
workflow definitions are pretty good. I would drop this and make changes to the existing definitions instead, if you have any improvements to suggest.
@@ -3,12 +3,13 @@ | |||
[![NPM](https://nodei.co/npm/s3rver.png)](https://nodei.co/npm/s3rver/) | |||
|
|||
[![Build Status](https://api.travis-ci.org/jamhall/s3rver.png)](https://travis-ci.org/jamhall/s3rver) | |||
![JavaScript files](https://github.com/jamhall/s3rver/workflows/JavaScript%20files/badge.svg) |
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.
It looks like we don't have this badge for the existing CI
workflow. If you're dropping the JavaScript files
workflow from this PR maybe change this to use the CI
badge instead of removing this line altogether.
![JavaScript files](https://github.com/jamhall/s3rver/workflows/CI/badge.svg)
Although adding the CI
workflow badge could be its own PR. It wouldn't be related to the rest of the work here.
[![Dependency Status](https://david-dm.org/jamhall/s3rver/status.svg)](https://david-dm.org/jamhall/s3rver) | ||
[![Devdependency Status](https://david-dm.org/jamhall/s3rver/dev-status.svg)](https://david-dm.org/jamhall/s3rver?type=dev) | ||
|
||
S3rver is a lightweight server that responds to **some** of the same calls [Amazon S3](http://docs.aws.amazon.com/AWSJavaScriptSDK/latest/AWS/S3.html) responds to. It is extremely useful for testing S3 in a sandbox environment without actually making calls to Amazon. | ||
|
||
The goal of S3rver is to minimise runtime dependencies and be more of a development tool to test S3 calls in your code rather than a production server looking to duplicate S3 functionality. | ||
The goal of S3rver is to minimize runtime dependencies and be more of a development tool to test S3 calls in your code rather than a production server looking to duplicate S3 functionality. |
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.
It makes sense to use the same English spelling conventions throughout the docs, but surely there would be more changes to add too. Consider dropping this change and creating a different PR to address English language spelling conventions.
const { address, port } = await server.run(); | ||
|
||
process.on('SIGINT', async function onSigint() { | ||
console.info('Got SIGINT. Graceful shutdown ', new Date().toISOString()); |
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.
Not sure this is a useful output. Would rather exit quietly.
const server = new S3rver(opts); | ||
const { address, port } = await server.run(); | ||
|
||
process.on('SIGINT', async function onSigint() { |
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.
From Node docs:
'SIGTERM' and 'SIGINT' have default handlers on non-Windows platforms that reset the terminal mode before exiting with code 128 + signal number. If one of these signals has a listener installed, its default behavior will be removed (Node.js will no longer exit).
I think this means you must call process.exit
inside these handlers or else the node
process won't be terminated via SIGINT
or SIGTERM
, you would have to send a SIGKILL
to terminate the process.
@@ -145,6 +161,8 @@ class S3rver extends Koa { | |||
|
|||
const { address, port, ...listenOptions } = this.serverOptions; | |||
this.httpServer = await this.listen(port, address, listenOptions); | |||
stoppable(this.httpServer); |
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.
I think I understand what .stop
patched by stoppable
is supposed to do, but I'm having trouble understanding why S3rver would benefit from it compared to using the .close
function.
S3rver is intended for integration testing, so when you call .close
you would probably want to perform cleanup as quickly as possible and do not care about open connections. If there are in-flight requests or Keep-Alive connections still open when you call .close
, you probably forgot to wait for your requests to end before cleaning up your tests, and you would want to receive errors about prematurely closed connections rather than have these connections silently cleaned up on close.
If you are running the process independently in the background or in a container, prematurely closed connections would indicate that you closed your server earlier than your tests completed, which IMO is fine and should be expected. It would be a little unexpected for that server to remain alive while my tests finish up their current requests, only to reject future requests and fail the remainder of the tests.
So I think there are no use cases where .stop
's graceful functionality would be useful, and would argue against introducing stoppable
for this reason. However if you can suggest a use case where graceful shutdown is needed I may reverse my opinion on this.
Close #637
Depends on #676 due formatting issues
Follow-up #637 due deleted fork