Search

Problem

NPM does not support git pointers to subfolders in the package.json file. This breaks the build.

Solutions

1. 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
2. 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
3. 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
4. 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
5. 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)
6. 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

[1] https://httpd.apache.org/docs/2.4/mod/core.html#allowencodedslashes