MARP-626 Introduce DEV-10 build for the connectors working on ivy 10

[phhung-axonivy]

Hi @weissreto @ivy-rew

I'm working on the story https://1ivy.atlassian.net/browse/MARP-626 to fix Dev-Fail on Market Monitor.
As the first step, I want to introduce a new Dev-10-Build build to watch the branch release/10, and trigger the build with the engine ivy nightly-10.0 for the connectors working on the ivy engine 10.
I will create a new branch release/10 for each market item working on the Ivy engine 10 and apply that build.
And for the Dev-build, it will watch only the branch master. We already have another story to convert projects to the latest version to resolve the failed Dev-build.

Please review this pull request and give us your feedback/ideas.
I'm looking forward to your feedback/ideas.

[weissreto]

I'm the wrong person to review this. @ivy-rew can you take over?

[ivy-rew]

Hi @phhung-axonivy

I think we can simplify this scenario, by making the existing 'CI' build more flexible. By introducing properties for the project-build-plugin in use, there is no longer any need to setup a special pipeline. We can simply override the plugin-version on a central location and therefore avoid the time consuming maintenance of a special release branch until the devs really have to do so.

See my PR #26, which makes the CI pipeline flexible enough, to comply with our current 11.4 environment:

I've adapted this approach by example on the msgraph-connector product: see axonivy-market/msgraph-connector#101

• a new 'ci-fork.yml' was introduced, that can be omitted as soon as Configurable Java and Maven version, using 21+3.9 for dev #26 is merged to master and tagged
• we only need to introduce a property to steer that project-build-plugin, rather than changing the project code and forcing the maintainers to keep multiple branches compatible. prototype: demonstrate flexible dev-pipeline msgraph-connector#100

I'd strongly suggest to use this approach as long as possible. IMHO we should delay the introduction of release branches as long as possible. We can do it shortly before or after the LTS12 release as most products remain compatible without any changes.

[phhung-axonivy]

Hi @ivy-rew
I completely agree with your approach. It's so cool.
However, we have another issue with Dev builds of some market items using Ivy Engine nightly-10.
At the current time, by default, the Dev build will download the latest nightly build (e.g. Ivy Engine 11.4.0).
So we will use the input ivyVersion: nightly-10.0 for the dev builds as a temporary solution to resolve this issue and remove this input after we have finished converting projects to the latest Ivy version.
I will close this pull request.

[ivy-rew]

However, we have another issue with Dev builds of some market items using Ivy Engine nightly-10. At the current time, by default, the Dev build will download the latest nightly build (e.g. Ivy Engine 11.4.0). So we will use the input ivyVersion: nightly-10.0 for the dev builds as a temporary solution to resolve this issue and remove this input after we have finished converting projects to the latest Ivy version. I will close this pull request.

@phhung-axonivy thanks for your openness for this change. Can you share an example repository where this happens? In theory the 'dev-pipeline' is meant to verify the compliance with the latest leading-edge version under development (now 11.4). So settings the ivyVersion to nightly-10.0 seems circumvent the target of the pipeline.

[phhung-axonivy]

@ivy-rew
We applied the nightly-10.0 on the repository https://github.com/axonivy-market/a-trust-connector/blob/master/.github/workflows/dev.yml.
The Dev build was successful. It's just a temporary solution to avoid failed dev builds at the current time.

There are many failed dev builds on the https://axonivy-market.github.io/market-monitor/. It looks not good. We have 70+ connectors, but we do not have enough time to convert projects and test all of them with the latest leading-edge version.
So @ivy-sgi created a task https://1ivy.atlassian.net/browse/MARP-626 to resolve it temporarily.

In addition, we have also a plan to convert projects and test them with the latest leading-edge version. After that, we will remove the settings of the ivyVersion: nightly-10.0 to keep the target of the 'dev-pipeline'.

Could you please share your idea?

[ivy-rew]

@ivy-rew We applied the nightly-10.0 on the repository https://github.com/axonivy-market/a-trust-connector/blob/master/.github/workflows/dev.yml. The Dev build was successful. It's just a temporary solution to avoid failed dev builds at the current time.

There are many failed dev builds on the https://axonivy-market.github.io/market-monitor/. It looks not good. We have 70+ connectors, but we do not have enough time to convert projects and test all of them with the latest leading-edge version. So @ivy-sgi created a task https://1ivy.atlassian.net/browse/MARP-626 to resolve it temporarily.

In addition, we have also a plan to convert projects and test them with the latest leading-edge version. After that, we will remove the settings of the ivyVersion: nightly-10.0 to keep the target of the 'dev-pipeline'.

Could you please share your idea?

I've just applied the same steps onto the a-trust-connectors as I did already on the msgraph-side.
axonivy-market/a-trust-connector#31
It works flawlessly without touching the productive code and we get real feedback onto the compatibility with leading-edge 11.4.
So I'd not further roll-out this 'nightly-10.0' target approach.
Rather we should introduce the properties as I did in msgraph and a-trust. This is mainly manual work where you could use the manpower of Octopus and Atomic @ivy-sgi .