ci: attempt to check in the CI build of the dist dir.

[chirino]

I think this should end up creating static-${ref} tags like static-main tags in the repo which will contain the built dist dir. If this does work, maybe we can change the crate to just use the existing dist files instead of doing a build?

[carlosthe19916]

@chirino thanks for PR, I really appreciate it.

• Do you mind creating also a PR into the trustify repository to have the full picture?
• I personally do not like the idea of creating tags for each commit into this repository. We can publish the tags in another repository and avoid polluting this one?

In general, I'm convinced (after all discussion internally) we all are not clear if we are doing this for "dev mode" or "prod mode".

• My personal interpretation of "dev mode" would be:
  • cargo run for starting the backend and npm run start:dev for starting the UI
• For Prod mode, we execute only the final binary generated by any kind of CI

What scenario do you think we are solving "dev mode"? or "prod mode"? I am not trying to block your PR but I would like to solve the problem and internal discussions sooner rather than later :)

[carlosthe19916]

Comment above

[chirino]

I agree with using another repo long term. But for the short term, it might be easier to use this one to validate the idea.

I think the dev/prod issue is that you have different types of dev mode. Some devs only want to do dev on the trusttify server, not the UI. This change will make life easier for those, as they won't need to build the UI bits every time they run the rust build.

[carlosthe19916]

Approving the PR as a vehicle to validate the idea but not the final solution

[chirino]

the latest attempt to check in the tag via CI failed with:

 create mode 100644 client/dist/monaco/ts.worker.js
 create mode 100644 client/dist/monaco/ts.worker.js.LICENSE.txt
 create mode 100644 client/dist/monaco/ts.worker.js.map
From https://github.com/trustification/trustify-ui
 * [new branch]      main       -> origin/main
remote: Permission to trustification/trustify-ui.git denied to github-actions[bot].
fatal: unable to access 'https://github.com/trustification/trustify-ui/': The requested URL returned error: 403
Error: Process completed with exit code 128.

So I think we need to update the github setting for this repo as described in https://stackoverflow.com/questions/72851548/permission-denied-to-github-actionsbot

[carlosthe19916]

• @chirino I have verified and this repository has already the correct permissions "red and write" for gh workflows
• The reason of the 403 error is that this PR comes from your forked repository and due to good security reasons it is not allowed to generate tags on the target repository through PRs. So your tag-dist job should never run against PRs but only on commits done in the main branch (this is a change to do in your PR). The following definition is what needs to be changed:

name: CI

on:
  push:
    branches:
      - main
      - "release-*"
  pull_request:
    branches:
      - main
      - "release-*"

• I didn't see any counterpart PR on https://github.com/trustification/trustify for using the changes done in this repository, is the expectation that no changes on the trustify repository will be needed? If not, I don't think it is a good idea to merge this PR without being sure it won't break things on the trustify repository. The trustify repository is already using the crate within the trustify-ui repository here https://github.com/trustification/trustify/blob/main/Cargo.toml#L130 and if you merge this PR without an immediate change to the trustify repo it will break the trustify repository intermediately. Let's avoid that because it will cause troubles to everyone working in the trustify repository.

I'd like us both to take a step back and validate ideas correctly before merging things on the main branch. What about this:

1. Using your forked repository execute the commands defined in this PR (either in a CI action or even manually in your terminal), then publish the tag in your forked repository.
2. Create a PR in the Trustify repository and make use of your forked-repository/tag here https://github.com/trustification/trustify/blob/main/Cargo.toml#L130
3. We can see how it goes and truly validate the idea without polluting neither trustify nor trustify-ui.

What do you think?

[chirino]

Will do.

[chirino]

Tried with this patch against trustify:

diff --git a/Cargo.toml b/Cargo.toml
index 8c2d1cd..a18b1c9 100644
--- a/Cargo.toml
+++ b/Cargo.toml
@@ -124,7 +124,7 @@ trustify-module-ui = { path = "modules/ui", default-features = false }
 trustify-module-advisory = { path = "modules/advisory" }
 trustify-module-vulnerability = { path = "modules/vulnerability" }
 trustify-server = { path = "server", default-features = false }
-trustify-ui = { git = "https://github.com/trustification/trustify-ui.git" }
+trustify-ui = { git = "https://github.com/chirino/trustify-ui.git", tag = "static-main" }

It built fine and UI loaded.

trustification/trustify#319

[carlosthe19916]

Thanks @chirino I think now I have a good understanding of your strategy in this PR. Sounds good to me

• After Use the static build of the trustify-ui trustify#319 is approved we can also merge this one.
• Later on the publishing of the tags must be done in another repository and not in this one
• The github action that generates the tags on each PR should not run on each PR but only on new commits on the main branch

[carlosthe19916]

This job should run only on:

on:
  push:
    branches:
      - main

Otherwise all new PRs will fail with 403, just like this current PR.

[chirino]

ah your right, I'll have to move this to different file then.

[chirino]

fixed and squashed

[chirino]

I can't merge. :(