kubaninc / scim_rails

06 Jul, 2020

1 commit

02 Jul, 2020

1 commit

  • a67fa0e6   Remove Gemfile.lock and update Ruby ... Browse File » 
    The Gemfile.lock is not a file that we want checked in with the gem. The
purpose of a Gemfile.lock is to lock in a combination of dependencies
for an application. In the case of a gem, we are just specifying the
limits for our dependency versions in the gemspec and are not locking in
a combination of dependencies (since ultimately, the application is
in charge of it's own dependencies).

The only effect the Gemfile.lock has in this project is for when running
it in the dummy app; is has no effect on any of the applications it's
installed in. The gem should work against the latest specified in it's
gemspec so there is no reason to pin the dummy app to the version in a
Gemfile.lock checked into source control.

More info in this blog post: https://yehudakatz.com/2010/12/16/clarifying-the-roles-of-the-gemspec-and-gemfile/
    Ross Reinhardt
     

02 Jun, 2020

1 commit

29 May, 2020

1 commit

  • 7ba7da5c   Add ability to supply a callable error handler ... Browse File » 
    resolves lessonly/scim_rails#23

Why?
The scim engine returns a custom response to the caller in the event
that there is a 500 error in the engine. It rescues any standard error
in order to do this.

Unfortunately this means that when something is broken it does not
bubble up to the parent app's error handling system or even be printed
in the logs.

We cannot just re-raise the exception because you cannot return a
response AND raise an exception as a part of the same request.

To help, this PR will make is possible for you to supply a callable
object that take the exception as it's argument.

If no callable object is provided, we will output the exception to the
logs so that silence is not the default.

To get the old behavior of completely ignoring an exception, you could
supply an empty proc.
    Ross Reinhardt
     

20 Dec, 2018

1 commit

11 Dec, 2018

1 commit

05 Nov, 2018

1 commit