export testresults as inlined ocm-resource

[GuezelS]

export testresults as inlined ocm-resource

commits.

Add unit-test job and attach test results to component descriptor

Add verify job and attach test-results + gosec-report to component descriptor

How to categorize this PR?

/area compliance
/kind enhancement
/platform openstack

What this PR does / why we need it:

Which issue(s) this PR fixes:
Fixes #

Special notes for your reviewer:

Release note:

export testresults as inlined ocm-resource

[hebelsan]

Hi @GuezelS,
What's the benefit from using this custom workflow over gardener/cc-utils/.github/workflows/sastlint-ocm.yaml?

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.
1 out of 2 committers have signed the CLA.

✅ GuezelS
❌ I764805

---

I764805 seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[GuezelS]

Hi @GuezelS, What's the benefit from using this custom workflow over gardener/cc-utils/.github/workflows/sastlint-ocm.yaml?

Because we require multiple OCM resource exports (gosec-report and test-results) from a single verification job. The sastlint is not attaching the test-results to the component descriptor.

[hebelsan]

Because we require multiple OCM resource exports (gosec-report and test-results) from a single verification job. The sastlint is not attaching the test-results to the component descriptor.

Wouldn't it make sense to extend the worklfow gardener/cc-utils/.github/workflows/sastlint-ocm.yaml@master in this case instead of adding this large job in every of our build worklfows?

[gardener-ci-robot]

The Gardener project currently lacks enough active contributors to adequately respond to all PRs.
This bot triages PRs according to the following rules:

• After 15d of inactivity, lifecycle/stale is applied
• After 15d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 7d of inactivity since lifecycle/rotten was applied, the PR is closed

You can:

• Mark this PR as fresh with /remove-lifecycle stale
• Mark this PR as rotten with /lifecycle rotten
• Close this PR with /close

/lifecycle stale