Details
-
Sub-task
-
Resolution: Fixed
-
L3 - Default
-
None
-
None
Description
Problem
NPM does not support git pointers to subfolders in the package.json file. This breaks the build.
Solutions
- A NPM post-install hook clones the platform repo and installs the CE Webapps
- Cons
- There might be authentication problems when cloning a maintenance repo
- Repo and credential management is usually done by Jenkins (conflict with the separation of concerns)
- Whenever the enterprise webapps are built, the platform repo needs to be cloned
- Might degrade development experience
- Pros
- Besides solving the problem with authentication, not much to do on the CI side
- Cons
- The Jenkins job clones the platform repo and the package.json of the EE Webapp points to a concrete folder
- Cons
- The currently used SCM plugin on Jenkins does not support cloning multiple repositories
- Bigger restructuring of CI jobs and release scripts/jobs
- Pros
- Better separation of concerns compared to solution #1
- Better development experience compared to solution #1
- Cons
- The CE Webapp NPM package is published to our Nexus, and the EE Webapp consumes the package from our Nexus
- Pros
- Low effort for the cambpm runtime team
- No CI changes; everything is in control of our own codebase
- Good development experience
- Cons
- NPM has no snapshot concept
- Currently, the Apache HTTP Server our Nexus is running on is configured in a way that URLs with escaped forward slashes are blocked, which breaks Nexus mirroring and is a blocker for this solution
- AllowEncodedSlashes [1] should be configured to On
- Infra has concerns:
- For the #infra team, it is time-consuming to configure and test Nexus so that NPM packages can be stored
- Nexus doesn’t seem to scale that well, and the #infra team doesn’t want to make us even more dependent on Nexus
- Pros
- Solution #3 but using GitHub packages instead of Nexus
- Cons
- NPM has no snapshot concept
- Published packages cannot be unpublished via the command line (but via automated GitHub action)
- Test release jobs and PR-based CI cannot easily run isolated
- Access token needed (Bot account needs to be added to our GitHub Org)
- Only 50 GB storage available (+0,25 $/GB) => We would need a cleanup concept (at least for the snapshot versions)
- Pros
- See Pros of Solution #3
- Cons
- Publish the CE frontend sources as maven artifact to Nexus and consume it in the EE Webapp
- Pros
- Compared to solution #3 and #4, we don't introduce new systems to our build processes
- We have profound knowledge about Maven and know how to rule it
- Effort is compared to all other solutions low for the cambpm runtime team as well as for the infra team
- Compared to solution #3 and #4, we can simply reuse the snapshot concept of Maven
- Cons
- Frontend build is dependent on the backend build (this is not really a valid point since we either link the repos or use the watch script during development)
- Pros
- Add package.json file to the root directory of the camunda-bpm-platform repository (brought up by martin.stamm)
- Pros
- Effort is compared to all other solutions low for the cambpm runtime team as well as for the infra team
- We can continue to use the git repository reference in the package.json of the EE repo
- Frontend build is not dependent on backend build (this is not really a valid point since we either link the repos or use the watch script during development)
- Cons
- The whole platform repository with all Java sources is cloned whenever npm i is executed (it takes one minute to download the whole repo)
- Seems a bit hacky, and people might wonder why we have a useless package.json in our repository root
- Pros
[1] https://httpd.apache.org/docs/2.4/mod/core.html#allowencodedslashes