Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: decouple ui container from backend #35

Merged
merged 13 commits into from
Nov 16, 2024

Conversation

carlosthe19916
Copy link
Member

No description provided.

@ctron
Copy link

ctron commented Oct 11, 2024

Using a different server than the existing backend (based on rust), will might lead to a lot of new tasks on the security process side of things. Which we should avoid IMO.

@carlosthe19916
Copy link
Member Author

  • We need to list exactly which are those security processes and be specific on how much impact it will have without assumptions.
  • I am sure there are more things than just fixing vulnerabilities but the fact that RHTPA V1 UI was based on Rust didn't prevent us to deal with npm security issues/tasks like this one https://issues.redhat.com/browse/TC-1770 . As long as there are npm dependencies we will need to deal with the tasks/issues related to it. And we already have a UI that contains npm dependencies. I'd like to understand how many tasks we are saving or increasing using a container just for the UI, considering the UI is already written in Typescript.

The reason of decoupling this is:

  • The Operator is being used to continuously execute e2e tests against the whole Trustify project. The e2e tests although slowly is/will grow and as long as the backend does not have an "up to date" version of the UI those tests will frequently fail.
  • @jcrossley3 is trying to continuously deploy the latest status of the project somewhere in the cloud. As long as the backend does not update the latest version of the UI after each commit done in the UI, the deployed version will always be outdated. Decoupling the backend and ui will allow the deployments to have always the latest version of both ui and backend as both create their containers after each commit is done in their respective repositories. This removes the need of the backend's source code always needing to manually update the version of the UI to be used.

@ctron
Copy link

ctron commented Oct 11, 2024

  • We need to list exactly which are those security processes and be specific on how much impact it will have without assumptions.

I agree. That should be part of the effort in evaluating the architecture.

  • I am sure there are more things than just fixing vulnerabilities […]

Correct.

carlosthe19916 and others added 12 commits October 12, 2024 11:50
# Conflicts:
#	src/main/resources/application.properties
# Conflicts:
#	src/main/java/org/trustify/operator/cdrs/v2alpha1/TrustifySpec.java
#	src/main/java/org/trustify/operator/controllers/TrustifyReconciler.java
# Conflicts:
#	src/main/java/org/trustify/operator/Constants.java
#	src/main/java/org/trustify/operator/controllers/TrustifyReconciler.java
# Conflicts:
#	src/main/java/org/trustify/operator/cdrs/v2alpha1/TrustifySpec.java
#	src/main/java/org/trustify/operator/controllers/TrustifyReconciler.java
#	src/test/java/org/trustify/operator/controllers/TrustifyReconcilerTest.java
# Conflicts:
#	src/main/resources/application.yaml
@carlosthe19916
Copy link
Member Author

https://github.com/trustification/trustify-helm-charts will be the official way of deploying Trustify. Therefore, this repository won't introduce any task for the security process while productizing Trustify

As of today the operator, this repository, is used only for CI and this PR will help always testing the very last version of both UI and Backend.

@carlosthe19916 carlosthe19916 merged commit 881b088 into trustification:main Nov 16, 2024
12 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants