Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
Need to address a few issues:
…agents don't respect Content-Disposition filename
Pass separate primary service and list of mirrors rather than treating the first of the services list as the primary. Nice fit for keyword args, and something we've long wanted in the equivalent Basecamp file repository. Upload returns the results of the underlying service uploads rather than the io.rewind result. Rewind before uploading rather than afterward, and demonstrate that behavior with a test. Test that more than one mirror works.
* Move service configuration from the Engine to Service * Delegate configuration mechanics to internal Service::Configurator * Delegate service building to the concrete Service classes, allowing them to configure composed services. * Implement for the Mirror service.
* Service.build takes the literal YAML config hash for the service and a reference to the Configurator that's doing the building. * Services that compose additional services can use the Configurator to look them up and build them by name. See MirrorService for an example. References #23
Since configuration is a nested hash we need to symbolize all keys of the hash. Othervise fetcing will fail on start
So tests pass when service configs aren't set up. References #28
* Use simple core API for duck-type compat with other clients * initialize: accept an existing client * initialize: accept arbitrary client args instead of a fixed, required set * download: use native get_object streaming, no need to implement range requests * exists?: use head_object (which returns immediately) rather than waiting for existence
When Active Storage is not loaded and direct_upload is used on file_field_tag we should not raise an exception.
FormHelper includes FormTagHelper so we don't need to define two methods
It's worth considering whether we should hide these by default, but I'm kinda thinking no. It's very reasonable that someone would want to call these directly, so they should be documented.
We are already removing the braces around hash parameters in the last argument in other places so we should not change the entire codebase because of two places.
And deal with a temporary test fix until we allow you to skip active storage.
What we want to test is that two different calls to isolate_namespace with the same module doesn't change the original railtie. We can do that defining two different railties. We can't call in the application because this method is not supposed to be called in an Application class.
If an AWS bucket name includes a `.` (e.g. `bucket.name`), then the canonical URL for an object will start with "https://s3.amazonaws.com/bucket.name/" and not with "https://bucket.name.s3.amazonaws.com/". The URL tests have now been separated into two separate asserts, to ensure that both the "s3.amazonaws.com" and the "bucket.name" components are included, but not specifically in that order.
This makes sense but I was wondering… what if your code didn't raise an error if you don't have
It's just a thought, inspired by the fact that
rescue LoadError logger.info "Skipping image analysis because the mini_magick gem isn't installed"