[DRAFT] - ci: integrate with global ci

[carlosthe19916]

@jcrossley3 @helio-frota this PR is just to show how to integrate this repo with the global tests https://github.com/trustification/trustify-ui-tests and https://github.com/trustification/trustify-api-tests

For each PR the tests will be executed.

This is a draft as you guys should find the appropriate way of creating the container images. I like to do it with Dockerfiles but it might not be what you guys prefer so I'll leave that to you.

The only purpose of this PR is to showcase how to make this repo run tests globally. Although as of today the repositories https://github.com/trustification/trustify-ui-tests and https://github.com/trustification/trustify-api-tests
do not have significant tests written there yet, but once I get into the UI work I should personally pay more attention to create UI e2e tests and enrich the https://github.com/trustification/trustify-ui-tests repo.

I have no idea how conflux works, neither what is the objective being pursued but I hope this helps somehow.

[helio-frota]

integrate this repo with the global tests

what is a global test ?

do not have significant tests written there yet,

I'm ok with this

[jcrossley3]

@carlosthe19916 thanks! I don't have a strong opinion on the Dockerfile, other than maybe its location within the source tree.

With this, I think all that's left is to deploy the image built by .github/workflows/container-latest.yaml to a public url hosted on AWS?

[carlosthe19916]

what is a global test ?

It would be a test that run against an instance of our project when all the pieces are all together, just like what you would expect to have if we were to release the project with what we have right now.

Just to give an example: currently this repository has nice tests but they are limited to test the backend, it does not test whether or not the backend actually breaks something in the UI. So the idea is to be able to test an instance that is as close as possible to what the customers will actually get when he uses our project. I mean, test production mode no dev mode artifacts.

[helio-frota]

yeah I agree, I think I asked wrong... global test in the meaning of some other tool but thanks for the clarification

[carlosthe19916]

@carlosthe19916 thanks! I don't have a strong opinion on the Dockerfile, other than maybe its location within the source tree.

With this, I think all that's left is to deploy the image built by .github/workflows/container-latest.yaml to a public url hosted on AWS?

I'll probably say nonsense but I think there are two different problems and each one will have a different solution:

• @PhilipCattanach mentioned that a goal is to be able to run integration tests. So this PR should cover that requirement as it executes all the tests we have against each PR and each commit done in the main branch. Moreover, there are nightly tests being executed in the trustify-ci repository.
• The second problem, as I understand, is to be able to deploy Trustify (for each commit or nightly) somewhere in the cloud and treat it as our staging environment.
  • If we were to deploy only upstream I would suggest just instantiating the operator in an OCP instance and leave the deploying task to Openshift. The way we can achieve it is to make the operator to be released nightly into a development channel and that's it, the operators will do all the magic for us (actually this is the way a real customer will receive updates from a product). This is an example of a nightly release of an operator operator sailoperator (0.2.0-nightly-2024-09-26) redhat-openshift-ecosystem/community-operators-prod#5234 (we currently do not release the operator nightly but if needed we can do it)
  • On the other hand, if we were to deploy the downstream version then the first step is to have Conflux (or whoever is responsible) to create the container images for downstream and then we can follow the same approach I mentioned about the operator.

This is just an idea. I personally do not support creating ArgoCD or things like that for deploying since it adds a new thing to maintain.

[helio-frota]

I'm still now understanding where I should configure/call those 2 TS and Java tests

/me feeling dumb again

[carlosthe19916]

I'm still now understanding where I should configure/call those 2 TS and Java tests

/me feeling dumb again

My apologies if I contributed to the confusion.
Probably there are things related to conflux that I do not understand neither anticipated (to me, mainly the definition of the requirement is not very clear as to upstream vs downstream). You guys are more close to the details than me, I was just trying to share some ideas, do not take my comments as a general truth but just as a brainstorm of ideas.

[helio-frota]

My apologies if I contributed to the confusion.

No worries I just left a different context 👍

Probably there are things related to conflux that I do not understand neither anticipated (to me, mainly the definition of the requirement is not very clear as to upstream vs downstream). You guys are more close to the details than me, I was just trying to share some ideas, do not take my comments as a general truth but just as a brainstorm of ideas.

👍

[ctron]

Not sure if we still consider this PR for merging at some point. If not, let's close it.

[jcrossley3]

This PR served as a model for the latest-release workflow, which relies on our existing action for building the image to be tested.