Support only 5.5 to 5.8

[dstepe]

I reduced support on this branch Laravel 5.5 - 5.8. Anyone wanting Laravel 6 or higher should use the 3.x branch.

I added a really basic test of the ServiceProvider to validate the method of fetching the log. That test can be expended to cover more behaviors of the ServiceProvider, but I suggest doing that on the 3.x branch and back-porting to here if we want.

I want to do some more real-world testing before this is merged, even though the tests are passing.

[arkaitzgarro]

You can remove the ScheduledTaskCollector class and the RecordTransaction middleware for jobs, as those are L6 specific.

[dstepe]

Closes #94

I think this is ready. The tests are passing on Laravel versions 5.5 through 5.8, including a new test of the ServiceProvider to make sure getting the Monolog instance works.

I'm not sure why the GitHub actions do not appear on this PR. They are running in my fork and have passed, though.

[arkaitzgarro]

I added the event to run GH actions on PRs, but those are failing here and not in your repo... I don't really get it.

Re-running the jobs solved the issue, computers...

[dstepe]

There is something very odd going on with the jobs. As you noted, they fail, but then succeed when re-run. I have observed that on more than one occasion, enough to suspect there is a real problem that needs to be addressed. Again this morning the jobs started by commit failed in your project but passed in mine. Re-running them in yours allowed them to pass.

I'm wondering if there is a cache order problem or something. I see that you are caching the composer cache directory, but not the vendor directory itself. I also see that the cache key in the unit test workflow includes the Laravel version, but the restore key does not. I don't know yet why any of that would make a difference, if it does at all. I'm just making observations at this point.

After some more reading on actions/cache@v2, the implementation make sense. I'm even more stumped now.

[arkaitzgarro]

Did you test it on real applications, to make a 2.0 release?

[arkaitzgarro]

There is something very odd going on with the jobs. As you noted, they fail, but then succeed when re-run. I have observed that on more than one occasion, enough to suspect there is a real problem that needs to be addressed. Again this morning the jobs started by commit failed in your project but passed in mine. Re-running them in yours allowed them to pass.

I'm wondering if there is a cache order problem or something. I see that you are caching the composer cache directory, but not the vendor directory itself. I also see that the cache key in the unit test workflow includes the Laravel version, but the restore key does not. I don't know yet why any of that would make a difference, if it does at all. I'm just making observations at this point.

After some more reading on actions/cache@v2, the implementation make sense. I'm even more stumped now.

It makes sense to be a caching problem, because Composer seems to install/load from cache correctly, but somehow some files are missing. If the problem persists, we can disable the cache as first measurement.

[dstepe]

@arkaitzgarro Yes, I neglected to mention, but I did run install and run each version of Laravel 5.5 through 5.8 with example app. It hits most of the major features and there were no obvious issues.