Fix potential github action smells

[ceddy4395]

Purpose

Hey! 🙂 I've made the following changes to your workflow:

• Use fixed version for runs-on argument
  • Using an explicit version for runs-on makes the developers more conscious about on what OS version they are testing/supporting. Furthermore, if breaking changes are introduced in the next version, they will not automatically break the pipeline.
• Avoid jobs without timeouts
  • Jobs without a timeout can cause runners to be occupied when some process falls into an infinite loop or has multiple retries to perform a certain task, which will inevitably fail. Furthermore, it is also useful to be notified when a test-suite all of a sudden takes a lot longer than it used to, considering keeping tests fast is a good practice.
• Steps should only perform a single command
  • Making sure every step has a single responsibility makes it easier to understand the workflow and, in case a workflow fails, it makes it clearer where and why it failed.

(These changes are part of a research Study at TU Delft looking at GitHub Action Smells. Find out more)

Description

Checklist

• [ ] New code follows the Google Java Style Guide\ This is automatically checked by mvn verify, but can also be checked on its own using mvn spotless:check.\ Style violations can be fixed using mvn spotless:apply; this can be done in a separate commit to verify that it did not cause undesired changes.
• [ ] If necessary, new public API validates arguments, for example rejects null
• [ ] New public API has Javadoc
  • [ ] Javadoc uses @since $next-version$
    ($next-version$ is a special placeholder which is automatically replaced during release)
• [ ] If necessary, new unit tests have been added
  • [ ] Assertions in unit tests use Truth, see existing tests
  • [ ] No JUnit 3 features are used (such as extending class TestCase)
  • [ ] If this pull request fixes a bug, a new test was added for a situation which failed previously and is now fixed
• [ ] mvn clean verify javadoc:jar passes without errors

[google-cla[bot]]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[ceddy4395]

@Marcono1234 Thank you for the review! I've made the changes you've suggested, including bumping the timeouts.

I've also made the same fixes to the other workflow files!

[eamonnmcmanus]

Thank you for doing this! Overall it looks good, but I'm not entirely convinced by this:

• Use fixed version for runs-on argument
  • Using an explicit version for runs-on makes the developers more conscious about on what OS version they are testing/supporting. Furthermore, if breaking changes are introduced in the next version, they will not automatically break the pipeline.

Would Dependabot or something else notify us if the latest supported version changes? Otherwise I'm afraid we'll never think to update it. I think I might rather discover that an Ubuntu update breaks our build as soon as it happens rather than months later, even if that means the CI mysteriously failing.

[Marcono1234]

Would Dependabot or something else notify us if the latest supported version changes?

No, that does not seem to be supported yet, see https://github.com/dependabot/dependabot-core/issues/7182.

[eamonnmcmanus]

Would Dependabot or something else notify us if the latest supported version changes?

No, that does not seem to be supported yet, see dependabot/dependabot-core#7182.

Thanks for that pointer. In that case, I'd suggest we leave this part as it is (with ubuntu-latest) until Dependabot does have that support.