OCP4: Add workflow to test ocp content

[Vincent056]

Add this workflow so we can test ocp4 content can be parsed on each PR

[Vincent056]

ComplianceAsCode/compliance-operator#493 needs to merge before this can work

[github-actions]

Start a new ephemeral environment with changes proposed in this pull request:

Fedora Environment

Oracle Linux 8 Environment

[github-actions]

🤖 A k8s content image for this PR is available at:
ghcr.io/complianceascode/k8scontent:11615
This image was built from commit: 894dfa9

Click here to see how to deploy it

If you alread have Compliance Operator deployed:
utils/build_ds_container.py -i ghcr.io/complianceascode/k8scontent:11615

Otherwise deploy the content and operator together by checking out ComplianceAsCode/compliance-operator and:
CONTENT_IMAGE=ghcr.io/complianceascode/k8scontent:11615 make deploy-local

[yuumasato]

Checking whether the compliance-operator can parse the data stream is important, but the test in https://github.com/ComplianceAsCode/compliance-operator/pull/493/files# seem too specific and contained.

I wonder if we could have a more thorough "smoke" integration test, something that runs CO and consumes the data stream.

[Vincent056]

Checking whether the compliance-operator can parse the data stream is important, but the test in https://github.com/ComplianceAsCode/compliance-operator/pull/493/files# seem too specific and contained.

I wonder if we could have a more thorough "smoke" integration test, something that runs CO and consumes the data stream.

the reason for this one I think is to have some gating on if CO can parse the datastream, but not to run a full on CI e2e job, however I think we can improve the test here

[rhmdnd]

Looks like this is on the right track. Just some feedback on isolating the test implementation details to the compliance-operator code base, so that the content repository doesn't need to understand how the test is implemented to call it.

[rhmdnd]

Are we going to have to bump this go version separately each time we bump it in the compliance-operator?

[Vincent056]

I think it will use the latest go,

Run go version
go version go1.22.0 linux/amd6[4](https://github.com/ComplianceAsCode/content/actions/runs/8007294791/job/21871061364?pr=11615#step:5:5)

[rhmdnd]

Oh - this is just enforcing a lower bound. Thanks.

[rhmdnd]

We will be testing with a version of golang (1.22) that's potentially different from the version of golang we build the operator with, correct?

So there would be a chance that the tests we invoke using https://github.com/ComplianceAsCode/compliance-operator/pull/493/files#diff-76ed074a9305c04054cdebb9e9aad2d818052b07091de1f20cad0bbac34ffb52R589 would break against the latest version of golang we're using here?

[Vincent056]

that's a good point, I changed this part to fetching the go version from the CO go.mod file

[Vincent056]

Looks like this is on the right track. Just some feedback on isolating the test implementation details to the compliance-operator code base, so that the content repository doesn't need to understand how the test is implemented to call it.

thanks for the review, just had those tests changed to use the make target instead.

[codeclimate]

Code Climate has analyzed commit 894dfa9 and detected 0 issues on this pull request.

The test coverage on the diff in this pull request is 100.0% (50% is the threshold).

This pull request will bring the total coverage in the repository to 58.1% (-1.1% change).

View more on Code Climate.

[Vincent056]

/retest

[rhmdnd]

My comments have been addressed, and I think we can start with this approach and iterate on it as needed.

Leave it open for @yuumasato to ensure his comments are addressed.

[yuumasato]

This PR is adding a new GH workflow, there is no need to rebase to trigger hardening tests.