Document and QE Usage of Dependencies Repositories in Airgap Scenario

[l0rd]

Is your enhancement related to a problem? Please describe.

As a developer working with Che and using the different default stacks packaged, the stacks should be configurable so that they are pointing we are to internal dependencies management tools (like artifactory or other).
It should be easy enough (documented and tested) to the customer and automated, to configure the stacks (and the associated devfile) so that they are rely on different dep management tools.

Describe the solution you'd like

Java/Maven/Gradle

It will be necessary to point build tools to local registries (maven's settings.xml, ~/.gradle/gradle.properties).
Often, local maven repos artifactories are using self signed certificates, so a customer will either have to create a keystore and add it to default java cacerts or define keystore in build commands (-DpropName=)

NodeJS

npm should be configured to be using a local registry (npm set registry? env var passed to)
If npm registry uses self signed certs, crt should be added to root ca in a container (rebuild an image) or npm should be aware of ca (npm config set ca ""?)

Other stacks

Similarly, other stacks like PHP or .NET may need such fine tuning to work with local registries/artifactories etc.

Subtasks

• STEP 1 Try out an document the manual setup of air-gapping for our various built systems:
  • maven Document Airgap Setup for Maven #15503
  • npm (assuming all relevant build systems use npm for package mgmt) Document Airgap Process for NPM #15501
  • gradle Document Airgap Setup for Gradle #15510
  • python Document Airgap Setup for Python #15664
  • nuget Document Airgap Setup for C# #15511
  • go packages Test and Document Airgap Setup for Go #15512
• STEP 2 Implement Airgapped Configuration Mechanism · Issue #15518 · eclipse/che

[tsmaeder]

Related issues:

• Why it downloads Gradle when I open a single java file Why it downloads Gradle when I open a single java file redhat-developer/vscode-java#901
• [Airgap] maven could not calculate build plan - settings.xml not used [Airgap] maven could not calculate build plan - settings.xml not used #14857

[tsmaeder]

Assuming this is about the "airgapped" case, we need to solve two distinct problems:

1. Override the settings from the source code (e.g. pom.xml) and default settings (e.g. maven central)
2. Make tools accept self-signed certificates for secure connections (e.g. https).

There are various desirable properties for any solution:

1. The solution should work for commands define in the devfile as well as using regular tools in the workspace (e.g. "mvn clean install" from the command line should work)
2. Ideally, an administrator could override settings in existing devfiles per che installation via some mechanism (I believe there is a cr.yaml file in CRW)
3. If there are relevant settings in the devfile, they should take precedence over those set per installation
4. If the user makes changes to any of the settings (for example, by editing a settings.xml in ~/.m2), they take precedence over system/devfile settings

[tsmaeder]

Step 1 is to try out an document the manual setup of air-gapping for our various built systems, in particular:

• maven Document Airgap Setup for Maven #15503
• npm (assuming all relevant build systems use npm for package mgmt) Document Airgap Process for NPM #15501
• gradle Document Airgap Setup for Gradle #15510
• python Document Airgap Setup for Python #15664
• nuget Document Airgap Setup for C# #15511
• go packages Test and Document Airgap Setup for Go #15512

[tsmaeder]

Step 2 (#15518) is to come up with one or more mechanisms for executing the configurations found in step 1 automatically as described above

[slemeur]

Step 0 should be to look at #14343 as it provides the basic mechanisms to configure the settings.xml used by a plugin from the devfile. We should:

• test how to enable that
• document a sample
• add that content on che-docs
  The most common ask we see is on configuring a settings.xml file. the others while important are less urgent.

[ericwill]

As per the discussion this morning, the implementation details will be discussed during other teams' prioritization calls. For now, the remaining action item for the plugins team is to ensure that all the documented items are in their proper upstream location (i.e. not in some Google doc).

[che-bot]

Issues go stale after 180 days of inactivity. lifecycle/stale issues rot after an additional 7 days of inactivity and eventually close.

Mark the issue as fresh with /remove-lifecycle stale in a new comment.

If this issue is safe to close now please do so.

Moderators: Add lifecycle/frozen label to avoid stale mode.