Adds a check with code coverage report: (#50)

- With a check it's possible to always see the code coverage results regardless  of the workflow event type
- Code Coverage threshold status is always reported on the check regardless of `fail_below_threshold` setting. This allows setting branch protection checks regardless of workflow status
- supports push event as well

No longer fails workflow if PR cannot be determined.

README.md

@@ -19,8 +19,16 @@ artifacts to circumvent this. See the workflows in this project for an implement
 
 ## How it looks like
 
+A comment is added to the pull request with the coverage report.
+
 ![alt text](img/comment.png "Pull request comment with metrics")
 
+A check is added to the workflow run.
+
+![alt text](img/check.png "Check with metrics")
+
+The check will suceed or fail based on your threshold, this allows you to mandate coverage checks pass on your [protected branches](https://docs.github.com/en/github/administering-a-repository/defining-the-mergeability-of-pull-requests/about-protected-branches).
+
 ## Inputs
 
 ### `repo_token` **Required**
@@ -79,6 +87,8 @@ Use a unique name for the report and comment.
 
 Pull request number associated with the report. This property should be used when workflow trigger is different than `pull_request`.
 
+If no pull request can determine the action will skip adding the comment.
+
 ## Example usage
 
 ```yaml

action.yml

@@ -40,7 +40,7 @@ inputs:
     required: false
     default: ''
   only_changed_files:
-    description: 'Only show coverage for changed files.'
+    description: 'Only show coverage for changed files. (only if a PR is present)'
     required: true
     default: false
   pull_request_number:

index.js

@@ -4,5 +4,6 @@ const { action } = require("./src/action");
 
 action(github.context.payload).catch((error) => {
   // Action threw an error. Fail the action with the error message.
+  core.debug(error.stack);
   core.setFailed(error.message);
 });