NEW: Modified project to use github actions/workflows

.github/workflows/ci.yml

@@ -0,0 +1,15 @@
+name: CI
+
+on:
+  push:
+  pull_request:
+
+jobs:
+  ci:
+    name: CI
+    uses: silverstripe/gha-ci/.github/workflows/ci.yml@v1
+    with:
+      phpcoverage_force_off: true
+      phplinting: false
+      doclinting: false
+      phpunit: true

README.md

@@ -1,19 +1,18 @@
 # Sentry.io integration for SilverStripe
 
-[![Build Status](https://api.travis-ci.org/phptek/silverstripe-sentry.svg?branch=master)](https://travis-ci.org/phptek/silverstripe-sentry)
+[![CI](https://github.com/phptek/silverstripe-sentry/actions/workflows/ci.yml/badge.svg)](https://github.com/phptek/silverstripe-sentry/actions/workflows/ci.yml)
 [![Scrutinizer Code Quality](https://scrutinizer-ci.com/g/phptek/silverstripe-sentry/badges/quality-score.png?b=master)](https://scrutinizer-ci.com/g/phptek/silverstripe-sentry/?branch=master)
 [![License](https://poser.pugx.org/phptek/sentry/license.svg)](https://github.com/phptek/silverstripe-sentry/blob/master/LICENSE.md)
 
-[Sentry](https://sentry.io) is an error and exception aggregation service. It takes your application's errors, aggregates them alongside configurable context and stores them for later analysis and debugging.
+[Sentry](https://sentry.io) and [Glitchtip](https://glitchtip.com) are error and exception aggregation services. Systems like these take your application's errors, aggregate them alongside configurable context and store them for triage and analysis.
 
 Imagine this: You see errors and exceptions before your clients do. The error > report > debug > patch > deploy cycle is therefore the most efficient it can possibly be.
 
-This module binds Sentry.io and hosted Sentry installations, to the Monlog error logger in SilverStripe. If you've used systems like
-[RayGun](https://raygun.com), [Rollbar](https://rollbar.com), [AirBrake](https://airbrake.io/) and [BugSnag](https://www.bugsnag.com/) before, you'll know roughly what to expect.
+This module binds sentry.io, app.glitchtip.com and on-prem hosted Sentry/Glitchtip installations to the Monlog error logger in Silverstripe. If you've used systems like [RayGun](https://raygun.com), [Rollbar](https://rollbar.com), [AirBrake](https://airbrake.io/) and [BugSnag](https://www.bugsnag.com/) before, you'll know roughly what to expect.
 
 ## Requirements
 
- See `composer.json`.
+ See `composer.json`
 
 ## Setup:
 
@@ -27,35 +26,35 @@ This module binds Sentry.io and hosted Sentry installations, to the Monlog error
 
 ## Config
 
-You can set your DSN as a first-class environment variable or via your project's `.env` file:
+You can set your DSN as a first-class environment variable in `.env` or your CI config:
 
     SENTRY_DSN="http://deacdf9dfedb24ccdce1b90017b39dca:[email protected]/44"
 
-Or you can set it in YML config, where you gain a little more flexibility and control:
-
-The following will get you errors reported in all environment modes: `dev`, `test` and `live`:
+You can also set it in your project's YML config:
 
     ---
     Name: my-project-config-sentry
     After:
       - 'sentry-config'
     ---
 
+    # Send errors reported for all environment modes: `dev`, `test` and `live` envs
+
     PhpTek\Sentry\Adaptor\SentryAdaptor:
       opts:
         # Example DSN only. Obviously you'll need to setup your own Sentry "Project"
         dsn: http://deacdf9dfedb24ccdce1b90017b39dca:[email protected]/44
 
 ### Conditional Config
 
-The following will get you errors reported just in `test` and `live` but not `dev`:
-
     ---
     Name: my-project-config-sentry
     After:
       - 'sentry-config'
     ---
 
+    # Send errors reported just in `test` and `live`, but not `dev` envs
+
     ---
     Only:
       environment: test
@@ -85,7 +84,7 @@ Please review the [usage docs](docs/en/usage.md) for further configuration and c
 
 Notes:
 
-* You can silence errors from `Injector` where "test" and "live" envs have `http_proxy` set, but "dev" environments don't. Just set `null` as the value. This applies to all YML config where some envs have a setting and others don't. For example:
+* Silence `Injector` errors where `test` and `live` envs have `http_proxy` set but `dev` environments don't: Provide a value of `null`, which applies to all YML config where one env has a setting and another doesn't. For example:
 
 ```
 ...
@@ -101,7 +100,7 @@ Notes:
 ...
 ```
 
-* As per the examples above, ensure your project's Sentry config is set to come *after* the module's own config, thus:
+* As per the examples above, ensure your project's config is set to come *after* the module's own config, thus:
 
     After:
       - 'sentry-config'
@@ -121,7 +120,7 @@ mysite/_config.php:
 
 ## Usage
 
-Sentry is normally setup once in your project's YML config or `_config.php` file. See the above examples and the [usage docs](docs/en/usage.md) for details and options.
+Sentry is normally setup once in your project's `.env`, YML config or even `_config.php` file. See the above examples and the [usage docs](docs/en/usage.md) for details and options.
 
 ## Support Me
 

docs/en/usage.md

@@ -1,15 +1,15 @@
 # Usage
 
-Once setup, everytime an `Exception` is thrown or PHP itself shuts down via `trigger_error()` etc or you "manually" trigger a log message to be sent to Sentry, all available data is automatically sent to your remote Sentry instance.
+Once setup, everytime an `Exception` is thrown or PHP itself shuts down via `trigger_error()` etc or you "manually" trigger a log message to be sent to your Sentry-compatible server, all available data is automatically sent to the server.s
 
-In addition to the module simply reporting all thrown `Exception`s, resulting in a stacktrace in Sentry itself, you can use Sentry as a simple logger with all the benefits of Sentry's tags and grouping. See the examples below.
+In addition to the module reporting all thrown `Exception`s which result in a stacktrace within Sentry or Glitchtip, the module can be used as a simple logger with all the benefits of Sentry's tagging and grouping. See the examples below.
 
 ## Environment
 
 For "manual" error-reporting, you can augment your message with some context. If an environment is not specified,
 the default is to use the return value of `Director::get_environment_type()`.
 
-SilverStripe 4 uses `Monolog` and individual handlers for logging. Once you instantiate a `Logger` object, you have access to `Monolog`'s public API.
+Silverstripe v4+ uses `Monolog` and individual handlers for logging. Once you instantiate a `Logger` object, you have access to `Monolog`'s public API.
 
     $config = ['env' => 'live'];
     $logger = Injector::inst()->createWithArgs(Logger::class, ['error-log'])
@@ -97,21 +97,20 @@ You can test how these messages appear in Sentry itself, by running the test tas
 
 ## Tags and Extras
 
-Sentry allows for custom key-value pairs to be recorded against each message that it is sent.
-These are known as "tags" and "extras" which allows for fine-grained grouping and filtering of messages via the Sentry UI.
+The Sentry API allows for custom key-value pairs to be recorded against each message that it is sent.
+These are known as "tags" and "extras" which allows for fine-grained grouping and filtering of messages via the Sentry or Glitchtip UI.
 
-Note: It makes no sense to send hugely varying data in a tag. If it's unlikely that a tag you
-wish to send is ever going to be repeated, don't send it as a tag. Look at using the "Extras" feature (also described below)
+Note: It makes no sense to send hugely varying data in a tag. If it's unlikely that a tag you wish to send is ever going to be repeated, don't send it as a tag. Look at using the "Extras" feature (also described below)
 instead.
 
     $config = [
-        // Appears in Sentry's "Details" tab on RHS and in the lozenges, located at the top
+        // Appears in server's "Details" tab on RHS and in the lozenges, located at the top
         'env' => 'live',
-        // Appears in Sentry's "Tags" tab as its own block and in the lozenges on the "Details" tab, located at the top
+        // Appears in the "Tags" tab as its own block and in the lozenges on the "Details" tab, located at the top
         'tags' => [
             'Unique-ID' => 44
         ],
-        // Appears in Sentry's "Details" tab under "Additional Data"
+        // Appears in the "Details" tab under "Additional Data"
         extra => [
             'Moon-Phase' => 'Full',
             'Tummy-Status' => 'Empty',
@@ -156,7 +155,7 @@ The module comes with some pre-defined **tags** and **extras** that are always s
 
 ## Stacktraces
 
-By default, the module will render Sentry's own stacktraces into Sentry's UI. However, you can configure the module to skip recording Silverstripe's own debugging internals as well as those of the module:
+By default, the module will render Sentry's own stacktraces into the server's UI. However, you can configure the module to skip recording Silverstripe's own debugging internals as well as those of the module:
 
 ```
 PhpTek\Sentry\Handler\SentryHandler:
@@ -167,7 +166,7 @@ Note that this feature should be considered experimental/incomplete. It is unabl
 
 ## Releases
 
-You can send Sentry your app's release-tag which causes it to attempt to relate bugs with a specific release, making it even easier to track the point at which an issue surfaced. 
+You can send your Sentry or Glitchtip server your app's release-tag which causes it to attempt to relate bugs to a specific release. This makes it even easier to track the point at which an issue surfaced.
 
 Note: The module's env variable name (below) is clearly not going to fit with your team's standards, regardless of what it's named. In this case it's expected that projects simply comprise two ENV vars which are assigned the same value in the same way within your CI setup.
 

phpunit.xml.dist

@@ -1,9 +1,11 @@
 <?xml version="1.0" encoding="UTF-8"?>
 <phpunit bootstrap="vendor/silverstripe/framework/tests/bootstrap.php" colors="true">
+  <testsuites>
     <testsuite name="Default">
         <directory>tests</directory>
     </testsuite>
     <testsuite name="sentry">
         <directory>tests</directory>
     </testsuite>
+  </testsuites>
 </phpunit>