add git action for pull requests

[wendelfabianchinsamy]

Purpose

Currently there is no git action workflow for pull requests. You need to merge the PR into master in order to ensure that your specs pass. This will allow you to know earlier if there are any failures which can then be fixed before merging into the master branch.

In the future, we can extend this workflow to include the execution of Rubocop, Bundle Audit, Brakeman, etc.

closes: #128

Approach

Open Questions and Pre-Merge TODOs

Learning

Types of changes

• Bug fix (non-breaking change which fixes an issue)

• New feature (non-breaking change which adds functionality)

• Breaking change (fix or feature that would cause existing functionality to change)

Reviewer, please remember our guidelines:

• Be humble in the language and feedback you give, ask don't tell.
• Consider using positive language as opposed to neutral when offering feedback. This is to avoid the negative bias that can occur with neutral language appearing negative.
• Offer suggestions on how to improve code e.g. simplification or expanding clarity.
• Ensure you give reasons for the changes you are proposing.

[wendelfabianchinsamy]

removed the caching steps as the gem action documentation suggests that setting bundler-cache: true will cache your gems (provided they are in the default Gemfile location).

[jrhoads]

Not a blocker but a suggestion

Since you are touching this, can you pull out the testing into it's own callable workflow file, similar to
the way lupo uses the same CI testing in pull requests/deployment/release

Ex:
https://github.com/datacite/lupo/blob/master/.github/workflows/pull_request.yml
and
https://github.com/datacite/lupo/blob/master/.github/workflows/parallel_ci.yml
(No need to do the stuff to run the specs in parallel here, they are much smaller/faster)

Then we just have one place to update if we need to update something related to tests/specs.

[digitaldogsbody]

Nice one @wendelfabianchinsamy - we should look at making this change in the workflows on other repos as well. Dealing with the caching stuff has always been a nightmare!

[wendelfabianchinsamy]

Not a blocker but a suggestion

Since you are touching this, can you pull out the testing into it's own callable workflow file, similar to the way lupo uses the same CI testing in pull requests/deployment/release

Ex: https://github.com/datacite/lupo/blob/master/.github/workflows/pull_request.yml and https://github.com/datacite/lupo/blob/master/.github/workflows/parallel_ci.yml (No need to do the stuff to run the specs in parallel here, they are much smaller/faster)

Then we just have one place to update if we need to update something related to tests/specs.

thanks @jrhoads. this is a great suggestion. I will get on it.

[digitaldogsbody]

Nice one @wendelfabianchinsamy - we should look at making this change in the workflows on other repos as well. Dealing with the caching stuff has always been a nightmare!

[wendelfabianchinsamy]

@jrhoads and @digitaldogsbody i've updated the pr with suggestions made by @jrhoads

[jrhoads]

The matrix is not needed. Since the tests complete in 9 seconds, we don't really gain anything by parallelizing them

[wendelfabianchinsamy]

thanks @jrhoads. i've updated the pr.

[jrhoads]

Looks good.