Employ Eclipse Dash to control 3rd party dependencies #2251

[ruspl-afed]

Add GitHub CI action to check 3rd party with Eclipse Dash.
"Automate IP team review requests" functionality requires API token to be asked via EF HelpDesk ticket by PL

Fixes #2251

[github-actions]

Test Results

  110 files  ±0    110 suites  ±0   1m 11s ⏱️ -1s
6 131 tests ±0  6 131 ✅ ±0  0 💤 ±0  0 ❌ ±0 
6 132 runs  ±0  6 132 ✅ ±0  0 💤 ±0  0 ❌ ±0 

Results for commit 7828424. ± Comparison against base commit a2ad76c.

♻️ This comment has been updated with latest results.

[ruspl-afed]

[Invalid workflow file: .github/workflows/licensecheck.yml#L28](https://github.com/eclipse-4diac/4diac-ide/actions/runs/22992989281/workflow)

The workflow is not valid. .github/workflows/licensecheck.yml (Line: 28, Col: 3): 
Error calling workflow 'eclipse-dash/dash-licenses/.github/workflows/mavenLicenseCheck.yml@master'. 
The nested job 'check-licenses' is requesting 'pull-requests: write', but is only allowed 'pull-requests: none'.

Perhaps it needs a bit more of configuration like here

      workflows+: {
        default_workflow_permissions: "write",
      },

@eclipsewebmaster please advice how to proceed

[azoitl]

@ruspl-afed at this point do I need to do something or are we still waiting for @eclipsewebmaster?

[mx990]

This is what we use for the Publish 4diac IDE Unit Test Results workflow:

4diac-ide/.github/workflows/unit-tests.yml

Lines 9 to 14 in 6647b24

	permissions:
	checks: write
	pull-requests: write
	contents: read
	issues: read
	actions: read

Could we not simply add the required permissions also to this workflow instead of changing the default?

[ruspl-afed]

Could we not simply add the required permissions also to this workflow instead of changing the default?

Brilliant comment @mx990 !
Thank you so much for sharing your expertise, I love to learn.

Now it works and highlights issues we have with Milo prerequisites.

[INFO] License information could not be automatically verified for the following content:
[INFO] 
[INFO] p2/orbit/p2.eclipse.plugin/wrapped.com.digitalpetri.fsm.strict-machine/0.7.0
[INFO] p2/orbit/p2.eclipse.plugin/wrapped.com.digitalpetri.netty.netty-channel-fsm/0.9.0
[INFO] p2/orbit/p2.eclipse.plugin/wrapped.com.google.guava.listenablefuture/9999.0.0.empty-to-avoid-conflict-with-guava
[INFO] p2/orbit/p2.eclipse.plugin/wrapped.com.google.j2objc.j2objc-annotations/3.0.0
[INFO] p2/orbit/p2.eclipse.plugin/wrapped.org.glassfish.jaxb.txw2/2.3.6

I suggest to care a bit about the shape of Milo libraries first in the scope of #2277 and then see how happy Dash will be.

@azoitl as a 4diac Project Lead you may want to request GITLAB_API_TOKEN secret for Dash via https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/issues
This will allow us to automate IP review process

[azoitl]

Could we not simply add the required permissions also to this workflow instead of changing the default?

Brilliant comment @mx990 ! Thank you so much for sharing your expertise, I love to learn.

Now it works and highlights issues we have with Milo prerequisites.

[INFO] License information could not be automatically verified for the following content:
[INFO] 
[INFO] p2/orbit/p2.eclipse.plugin/wrapped.com.digitalpetri.fsm.strict-machine/0.7.0
[INFO] p2/orbit/p2.eclipse.plugin/wrapped.com.digitalpetri.netty.netty-channel-fsm/0.9.0
[INFO] p2/orbit/p2.eclipse.plugin/wrapped.com.google.guava.listenablefuture/9999.0.0.empty-to-avoid-conflict-with-guava
[INFO] p2/orbit/p2.eclipse.plugin/wrapped.com.google.j2objc.j2objc-annotations/3.0.0
[INFO] p2/orbit/p2.eclipse.plugin/wrapped.org.glassfish.jaxb.txw2/2.3.6

I suggest to care a bit about the shape of Milo libraries first in the scope of #2277 and then see how happy Dash will be.

Great that we have that. Eclipse Milo was always one of our harder to handle dependencies. Knowing more about it is important. I also provided more feedback especially on Eclipse Milo changes on #2277.

@azoitl as a 4diac Project Lead you may want to request GITLAB_API_TOKEN secret for Dash via https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/issues This will allow us to automate IP review process

Done: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/issues/7287

@ruspl-afed If I understand correctly we need to first fix our Eclipse Milo dependencies and have the GITLAB_API_TOKEN before we can merge this, so that the builds are not always failing. Am I right?

[ruspl-afed]

@ruspl-afed If I understand correctly we need to first fix our Eclipse Milo dependencies and have the GITLAB_API_TOKEN before we can merge this, so that the builds are not always failing. Am I right?

we need to first fix our Eclipse Milo dependencies

yes, I would do so, otherwise all the PRs will be failing

and have the GITLAB_API_TOKEN before we can merge this

It's kind of an "orthogonal" thing: GITLAB_API_TOKEN token is needed only for "Send these newly added 3rd party libs to IP team for Review" scenario, which is nice to have.

[azoitl]

and have the GITLAB_API_TOKEN before we can merge this

It's kind of an "orthogonal" thing: GITLAB_API_TOKEN token is needed only for "Send these newly added 3rd party libs to IP team for Review" scenario, which is nice to have.

Yes this would definitely be nice.

[azoitl]

@ruspl-afed we have a token now.

[ruspl-afed]

now it looks much better

[INFO] License information could not be automatically verified for the following content:
[INFO] 
[INFO] p2/orbit/p2.eclipse.plugin/wrapped.com.digitalpetri.fsm.strict-machine/1.0.0
[INFO] p2/orbit/p2.eclipse.plugin/wrapped.com.digitalpetri.netty.netty-channel-fsm/1.0.2
[INFO] 
[INFO] This content is either not correctly mapped by the system, or requires review.

however, after investigating Milo pom.xml I don't think that it looks better, since a lot of "com,google" code is just hidden/repackaged inside the shaded jars.

I think we need to discuss this issue @azoitl

[azoitl]

Thank you @ruspl-afed to explain to issue with the current Eclipse Milo setup to me. To derive a plan I want to quickly summarize it here: Eclipse Milo packages more into their maven packages as they should. This is not wrong and makes consuming easier however it is not good for maintenance especially on our side. Therefore I propose as intermediate solution to introduce a dedicated OPC UA deployment feature which will per default not be included in the product but can be added to it by users. This allows us to move forward with better SBOM generation and tracking and in parallel we can search for solutions how to better use Milo.

@mx990 @ernstblechaPT @m-meingast is there a flaw in my proposal of haveing an OPC UA deployment feature?

[mx990]

I believe that is a sensible solution for the problem at hand, considering OPC UA is also an optional feature in 4diac FORTE.

[ernstblechaPT]

Just to restate what I understand:

• the target platform will contain the Milo dependency
• the product will not reference the opcua-deployment-feature
• the opcua-deployment-feature will still be built and can be manually installed from the updatesite

[azoitl]

Just to restate what I understand:

* the target platform will contain the Milo dependency
* the product will not reference the opcua-deployment-feature
* the opcua-deployment-feature will still be built and can be manually installed from the updatesite

Yes exactly, this is what I meant.

[azoitl]

OPC UA Deployment feature is extracted in PR #2414.