Hide sidebar #690

schlagtim · 2021-12-13T14:02:05Z

Add runtime environment variables
- Will be injected when running the BPA container
- Can be read from frontend code
Add runtime variables:
- SIDEBAR_CLOSE_ON_STARTUP: Hides sidebar in UI when opening any frontend page (can still be opened via burger button); "true", "false"
- SIDEBAR_HIDE_BURGER_BUTTON: Hides the burger button to open/close sidebar independent from above setting; "true", "false"

To hide the sidebar entirely, set both to true e.g. in your docker-compose as environment variables

Signed-off-by: Tim Schlagenhaufer <tim.schlagenhaufer@bosch.io>

…et + typings Signed-off-by: Tim Schlagenhaufer <tim.schlagenhaufer@bosch.io>

Signed-off-by: Tim Schlagenhaufer <tim.schlagenhaufer@bosch.io>

etschelp · 2021-12-13T14:42:36Z

Dockerfile

 EXPOSE 8080
-CMD java -XX:+UnlockExperimentalVMOptions -Dcom.sun.management.jmxremote ${JAVA_OPTS} -jar business-partner-agent.jar
+CMD ./setup-runtime.sh public/env.js business-partner-agent.jar && java -XX:+UnlockExperimentalVMOptions -Dcom.sun.management.jmxremote ${JAVA_OPTS} -jar business-partner-agent.jar


How does this impact start performance?

About 5 seconds, the script will start after everything else has been set up

etschelp · 2021-12-13T14:43:18Z

Dockerfile

+COPY --from=VUE /frontend/setup-runtime.sh setup-runtime.sh
+
+RUN \
+    mkdir public && \


Why the public folder, are the contents of the .jar extracted there?

The public folder is necessary because the jar tool ("jar uf") requires the same path of the file to modify the file in the existing jar file. See: https://docs.oracle.com/javase/tutorial/deployment/jar/update.html
There does not seem to be way around this (the jar uf -C option does not provide an alternative)

frontend/package.json

etschelp · 2021-12-13T14:46:52Z

frontend/package.json

@@ -6,26 +6,26 @@
    "serve": "vue-cli-service serve",
    "build": "vue-cli-service build",
    "test:unit": "vue-cli-service test:unit",
-    "lint": "vue-cli-service lint && npm run license-file-headers-add",


where is this now?

The license-file-headers-add script is called via lint-staged, so in .lintstagedrc.json.
It should not be included in the build, as it could worst case create pending file changes, which would probably impact build pipelines.
Headers should be created during development, before committing.

makes sense. the backend build fails in this case is it possible to have the same behavior here?

Yes, the license-check-and-add package offers a "check" option we could use in the build script (before starting the actual "vue-cli-service build" task). If it fails, the build fails. I can add it in a new commit

Can you have a look to the build.yml there we have:

# Test Phase - name: Test with npm ## TODO are there any frontend tests? run: npm --prefix frontend run license-check

I think it makes sense to add something similar

Yes, we can add one here too. The build should fail as early as possible in this case (missing license headers) as it is not resource intensive. Where do you think we should add it in the build.yml file?

As another step in the test phase

Added the step in new commit

Signed-off-by: Tim Schlagenhaufer <tim.schlagenhaufer@bosch.io>

etschelp · 2021-12-13T15:44:50Z

frontend/package.json

-    "lint": "vue-cli-service lint && npm run license-file-headers-add",
-    "prettify": "prettier --write **/*.{css,html,js,json,mjs,scss,ts,tsx,yml,md,vue}",
+    "lint": "vue-cli-service lint",
+    "prettify": "npm run license && prettier --write **/*.{css,html,js,json,mjs,scss,ts,tsx,yml,md,vue}",


npm run license is also called in the build.yml will this cause issues?

This most likely won't cause any issues as it only creates a new licenses/licenseInfos.json file. Since it won't be committed in the build, it does not cause any problems. It actually is a good thing it's called in the build, since the result will always have the current dependency versions listed in the frontend.
The prettify script is currently for development and not part of a build chain (prettier calls should always happen before pushes and not on the pipeline).

etschelp · 2021-12-13T15:46:37Z

frontend/setup-runtime.sh

+# Second argument: Path to BPA jar file to replace env.js
+echo "Start setting runtime variables"
+
+# Overwrite frontend runtime variables with environment variables from container


What happens if the properties are not set, what is the default? Also would it make sense to skip in this case, meaning wrap this into something like if [ -z ... ];

When the properties/env variables are not set, the system will pass an empty string ("") which replaces the value of the respective identically named environment variable in env.js. Example:

MY_VARIABLE is not set in e.g. docker-compose

which then turns this
window.env = { MY_VARIABLE: "__MY_VARIABLE__", };

into this:

window.env = { MY_VARIABLE: "", };

inside the jar.
If MY_VARIABLE is set to e.g. "true", "false" or anything else (e.g. "asdasd") it will be replaced accordingly.
Naturally, validation of the value needs to be done in the frontend, which for boolean values is included in this PR.
An empty string or an incorrect value does not break the code, it will be turned into "undefined".

Skipping this would make sense to save a little bit of startup time. We probably should discuss these kind of changes beforehand or in a different draft.

As this is something only some users need we should keep the impact on the others as minimal as possible so I prefer the option to skip. We can do this in a second pr if you like.

Yes, I totally agree. Since this functionality is now stable and testing takes a lot of time (rebuilding Docker images on changes) we should create a separate PR and branch to improve this script.
A.k.a if no variable is set - skip all. Only perform the edit for variables that are set.

Signed-off-by: Tim Schlagenhaufer <tim.schlagenhaufer@bosch.io>

etschelp · 2021-12-13T16:28:54Z

frontend/package.json

@@ -4,28 +4,29 @@
  "private": true,
  "scripts": {
    "serve": "vue-cli-service serve",
-    "build": "vue-cli-service build",
+    "build": "npm run license-file-headers-check && vue-cli-service build",


as this is now a build step this should not be needed anymore

Removed in most recent commit

…from build script Signed-off-by: Tim Schlagenhaufer <tim.schlagenhaufer@bosch.io>

schlagtim added 6 commits December 9, 2021 19:08

Add runtime variables for frontend via container

7515cfd

Signed-off-by: Tim Schlagenhaufer <tim.schlagenhaufer@bosch.io>

Update build Dockerfile to support runtime variables

99895b6

Signed-off-by: Tim Schlagenhaufer <tim.schlagenhaufer@bosch.io>

Disable reopening of sidebar on screen size change when variable is s…

c65c6a0

…et + typings Signed-off-by: Tim Schlagenhaufer <tim.schlagenhaufer@bosch.io>

Update dependencies + fix duplicate burger button

a6b55a3

Signed-off-by: Tim Schlagenhaufer <tim.schlagenhaufer@bosch.io>

Merge remote-tracking branch 'origin/master' into feature/sidebar

ba0b250

Update license versions

dac7231

Signed-off-by: Tim Schlagenhaufer <tim.schlagenhaufer@bosch.io>

etschelp reviewed Dec 13, 2021

View reviewed changes

schlagtim added 2 commits December 13, 2021 16:01

Add license generator step to prettify script

9fae142

Signed-off-by: Tim Schlagenhaufer <tim.schlagenhaufer@bosch.io>

Add license header check before build

c8ba2fb

Signed-off-by: Tim Schlagenhaufer <tim.schlagenhaufer@bosch.io>

etschelp reviewed Dec 13, 2021

View reviewed changes

Add license header check to pipeline test phase

8050b6c

Signed-off-by: Tim Schlagenhaufer <tim.schlagenhaufer@bosch.io>

etschelp reviewed Dec 13, 2021

View reviewed changes

Ignore husky temporary files for license header check + remove check …

3368501

…from build script Signed-off-by: Tim Schlagenhaufer <tim.schlagenhaufer@bosch.io>

etschelp merged commit 71bc759 into hyperledger-labs:main Dec 13, 2021

schlagtim deleted the feature/sidebar branch January 11, 2022 15:39

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Hide sidebar #690

Hide sidebar #690

schlagtim commented Dec 13, 2021 •

edited by gitpod-io bot

Loading

etschelp Dec 13, 2021

schlagtim Dec 13, 2021

etschelp Dec 13, 2021

schlagtim Dec 13, 2021

etschelp Dec 13, 2021

schlagtim Dec 13, 2021

etschelp Dec 13, 2021

schlagtim Dec 13, 2021

schlagtim Dec 13, 2021

etschelp Dec 13, 2021

schlagtim Dec 13, 2021

etschelp Dec 13, 2021

schlagtim Dec 13, 2021

etschelp Dec 13, 2021

schlagtim Dec 13, 2021 •

edited

Loading

etschelp Dec 13, 2021

schlagtim Dec 13, 2021

etschelp Dec 13, 2021

schlagtim Dec 13, 2021

etschelp Dec 13, 2021

schlagtim Dec 13, 2021

Hide sidebar #690

Hide sidebar #690

Conversation

schlagtim commented Dec 13, 2021 • edited by gitpod-io bot Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

schlagtim Dec 13, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

schlagtim commented Dec 13, 2021 •

edited by gitpod-io bot

Loading

schlagtim Dec 13, 2021 •

edited

Loading