Bump pf

.github/workflows/ci-global.yml

@@ -0,0 +1,54 @@
+name: CI (global konveyor CI)
+
+on:
+  push:
+    branches:
+      - "main"
+  pull_request:
+    branches:
+      - "main"
+
+###
+# The global CI settings need to be adjusted for the `release-*`` branches such that:
+#  1. The operator uses the correct `:release-*` images
+#  2. The `*-tests_ref` use the correct branches
+#
+# on:
+#   push:
+#     branches:
+#       - 'main'
+#       - 'release-*'
+#   pull_request:
+#     branches:
+#       - 'main'
+#       - 'release-*'
+##
+
+concurrency:
+  group: ci-global-${{ github.ref }}
+  cancel-in-progress: true
+
+jobs:
+  build-and-upload-for-global-ci:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+
+      - name: save tackle2-ui image
+        run: |
+          docker build . -t quay.io/konveyor/tackle2-ui:latest
+          docker save -o /tmp/tackle2-ui.tar quay.io/konveyor/tackle2-ui:latest
+
+      - name: Upload tackle2-ui image as artifact
+        uses: actions/upload-artifact@v3
+        with:
+          name: tackle2-ui
+          path: /tmp/tackle2-ui.tar
+          retention-days: 1
+
+  run-global-ci:
+    needs: build-and-upload-for-global-ci
+    uses: konveyor/ci/.github/workflows/global-ci.yml@main
+    with:
+      component_name: tackle2-ui
+      run_api_tests: false

.github/workflows/ci-repo.yml

@@ -0,0 +1,55 @@
+name: CI (repo level)
+
+on:
+  push:
+    branches:
+      - "main"
+      - "release-*"
+  pull_request:
+    branches:
+      - "main"
+      - "release-*"
+
+env:
+  # Note: This should match the node version(s) used in the base Dockerfile
+  node-version: "18"
+
+jobs:
+  unit-test:
+    runs-on: ubuntu-latest
+
+    steps:
+      - uses: actions/checkout@v4
+
+      - name: Use Node.js (version "${{ env.node-version }}")
+        uses: actions/setup-node@v4
+        with:
+          node-version: ${{ env.node-version }}
+          cache: "npm"
+
+      - name: Verify package-lock.json
+        run: ./scripts/verify_lock.mjs
+
+      - name: Install
+        run: npm clean-install --ignore-scripts
+
+      - name: Lint sources
+        run: npm run lint
+
+      - name: Build
+        run: npm run build
+
+      - name: Test
+        run: npm run test -- --coverage --watchAll=false
+
+      - name: Upload to codecov (client)
+        uses: codecov/codecov-action@v4
+        with:
+          flags: client
+          directory: ./*/coverage
+
+      - name: Upload to codecov (server)
+        uses: codecov/codecov-action@v4
+        with:
+          flags: server
+          directory: ./*/coverage

.github/workflows/image-build.yaml

@@ -21,6 +21,7 @@ jobs:
       image_name: "tackle2-ui"
       containerfile: "./Dockerfile"
       architectures: '[ "amd64", "arm64", "ppc64le", "s390x" ]'
+      extra-args: "--ulimit nofile=4096:4096"
     secrets:
       registry_username: ${{ secrets.QUAY_PUBLISH_ROBOT }}
       registry_password: ${{ secrets.QUAY_PUBLISH_TOKEN }}

.github/workflows/issues.yaml

@@ -0,0 +1,30 @@
+name: Reconcile GitHub Issue (Comment)
+
+on:
+  issues:
+    types:
+      - opened
+      - edited
+      - closed
+      - reopened
+      - labeled
+      - unlabeled
+  issue_comment:
+    types:
+      - created
+      - edited
+
+concurrency:
+  group: reconcile-issue-${{ github.event.issue.number }}-${{ github.event_name }}
+  cancel-in-progress: true
+
+jobs:
+  reconcile-issue:
+    if: github.event_name == 'issues' || github.event_name == 'pull_request'
+    secrets: inherit
+    uses: konveyor/release-tools/.github/workflows/reconcile-issue.yaml@main
+
+  reconcile-issue-comment:
+    if: github.event_name == 'issue_comment'
+    secrets: inherit
+    uses: konveyor/release-tools/.github/workflows/reconcile-issue-comment.yaml@main

.github/workflows/pr-closed.yaml

@@ -13,4 +13,5 @@ jobs:
       pull-requests: write
       contents: write
     if: github.event.pull_request.merged == true
+    secrets: inherit
     uses: konveyor/release-tools/.github/workflows/cherry-pick.yml@main

BRANDING.md

@@ -0,0 +1,151 @@
+# Branding
+
+The UI supports static branding at build time. Dynamically switching brands is not
+possible with the current implementation.
+
+## Summary
+
+Each of the project modules need to do some branding enablement.
+
+- `@konveyor-ui/common` pulls in the branding assets and packages the configuration,
+  strings and assets within the common package. The other modules pull branding
+  from the common module.
+
+- `@konveyor-ui/client` uses branding from the common package:
+
+  - The location of `favicon.ico`, `manifest.json` and any other branding
+    assets that may be referenced in the `brandingStrings` are sourced from the
+    common package.
+
+  - The `brandingStrings` are used by the dev-server runtime, to fill out the
+    `index.html` template.
+
+  - The about modal and application masthead components use the branding strings
+    provided by the common module to display brand appropriate logos, titles and
+    about information. Since the common module provides all the information, it
+    is packaged directly into the app at build time.
+
+- `@konveyor-ui/server` uses the `brandingStrings` from the common package to fill
+  out the `index.html` template.
+
+## Providing alternate branding
+
+To provide an alternate branding to the build, specify the path to the branding assets
+with the `BRANDING` environment variable. Relative paths in `BRANDING` are computed
+from the project source root.
+
+Each brand requires the presence of at least the following files:
+
+- `strings.json`
+- `favicon.ico`
+- `manifest.json`
+
+With a file path of `/alt/custom-branding`, a build that uses an alternate branding
+is run as:
+
+```sh
+> BRANDING=/alt/custom-branding npm run build
+```
+
+The dev server can also be run this way. Since file watching of the branding assets
+is not implemented in the common module's build watch mode, it may be necessary to
+manually build the common module before running the dev server. When working on a
+brand, it is useful to run the dev server like this:
+
+```sh
+> export BRANDING=/alt/custom-branding
+> npm run build -w common
+> npm run start:dev
+> unset BRANDING # when you don't want to use the custom branding path anymore
+```
+
+### File details
+
+#### strings.json
+
+The expected shape of `strings.json` is defined in [branding.ts](./common/src/branding.ts).
+
+The default version of the file is [branding/strings.json](./branding/strings.json).
+
+A minimal viable example of the file is:
+
+```json
+{
+  "application": {
+    "title": "Konveyor"
+  },
+  "about": {
+    "displayName": "Konveyor"
+  },
+  "masthead": {}
+}
+```
+
+At build time, the json file is processed as an [ejs](https://ejs.co/) template. The
+variable `brandingRoot` is provided as the relative root of the branding
+assets within the build of the common module. Consider the location of `strings.json`
+in your branding directory as the base `brandingRoot` when creating a new brand.
+
+For example, to properly reference a logo within this branding structure:
+
+```
+  special-brand/
+    images/
+      masthead-logo.svg
+      about-logo.svg
+    strings.json
+```
+
+Use a url string like this:
+
+```json
+{
+  "about": {
+    "imageSrc": "<%= brandingRoot %>/images/about-logo.svg"
+  }
+}
+```
+
+and in the output of `BRANDING=special-brand npm run build -w common`, the `imageSrc`
+will be `branding/images/about-logo.svg` with all of the files in `special-branding/*`
+copied to and available to the client and server modules from
+`@konveyor-ui/common/branding/*`.
+
+#### favicon.ico
+
+A standard favorite icon file `favicon.ico` is required to be in the same directory
+as `strings.json`
+
+#### manifest.json
+
+A standard [web app manifest](https://developer.mozilla.org/en-US/docs/Web/Manifest)
+file `manifest.json` is required to be in the same directory as `strings.json`.
+
+## Technical details
+
+All branding strings and assets are pulled in to the common module. The client and
+server modules access the branding from the common module build.
+
+The `common` module relies on rollup packaging to embed all of the brand for easy
+use. The use of branding strings in `client` and `server` modules is straight forward.
+Pulling in `strings.json` and providing the base path to the brand assets is a
+more complicated.
+
+The `common` module provides the `brandingAssetPath()` function to let the build time
+code find the root path to all brand assets. Webpack configuration files use this
+function to source the favicon.ico, manifest.json and other brand assets to be copied
+to the application bundle.
+
+The `brandingStrings` is typed and sourced from a json file. To pass typescript builds,
+a stub json file needs to be available at transpile time. By using a typescript paths
+of `@branding/strings.json`, the stub json is found at transpile time. The generated
+javascript will still import the path alias. The
+[virtual rollup plugin](https://github.com/rollup/plugins/tree/master/packages/virtual)
+further transform the javascript output by replacing the `@branding/strings.json` import
+with a dynamically built module containing the contents of the brand's `strings.json`.
+The brand json becomes a virtual module embedded in the common module.
+
+A build for a custom brand will fail (1) if the expected files cannot be read, or (2)
+if `strings.json` is not a valid JSON file. **Note:** The context of `stings.json` is
+not currently validated. If something is missing or a url is malformed, it will only
+be visible as a runtime error.

Dockerfile

@@ -3,7 +3,7 @@ FROM registry.access.redhat.com/ubi9/nodejs-18:latest as builder
 
 USER 1001
 COPY --chown=1001 . .
-RUN npm clean-install && npm run build && npm run dist
+RUN npm clean-install --ignore-scripts && npm run build && npm run dist
 
 # Runner image
 FROM registry.access.redhat.com/ubi9/nodejs-18-minimal:latest