CI Testing Infrastructure

[fluidnumerics-joe]

To help us handle PR review, I'd like to start a discussion on CI infrastructure and testing requirements to help us merge in contributions. To kick this off, here's a few suggestions on what we need to be checking for and how we might do it.

Code Formatting
To maintain consistent formatting, tools like fprettify can help. From the developers side, we can provide specific flags to use that will apply the formatting standards we choose to enforce. From the testing side, such a tool can be used to help verify whether or not format standards are met.

Functionality & Portability
Generally, we need to be able to demonstrate positive answers to the following questions

• Does it build ?
• Does it run ?
• Does it get the right result ?
  on a range of hardware. Following the ROCm and HIP motifs of portability, we likely want to be running these tests on AMD and Nvidia GPUs. This being said, whatever CI platform we use needs to be able to accommodate both AMD and Nvidia GPUs to make sure that hipfort is portable.

It looks like the hipfort repository is set up with tests handled under Cmake and it seems that running tests is straightforward.

CI Infrastructure Strategy
Ultimately, CI infrastructure needs to be heterogeneous. One strategy is to leverage Google Cloud Build with additional steps to perform tests on GCE instances. This could provide access to Nvidia hardware. To expose AMD hardware we could federate a Slurm cluster on GCP to another cloud provider or on-premise system.

I'm interested to know what other maintainers on this repository have thought about with regards to CI for hipfort and if we can come to a consensus on how to do this.

@gregrodgers @pbauman @txomin13

[doctorcolinsmith]

We now have some CI jobs enabled internally for basic tests. There is still some work to enable all test jobs and have results reported back on PRs.