Support to allow settings in code repository

[hohwille]

As a IDEasy admin, I want to have the ability to keep my settings together with the code in the same git repo so that I can change IDE setttings on feature branches (e.g. java or maven updates together with according code-changes in the same Pull-Request).

Warning

This will not be the default. We designed the settings repo separated from the code repo for good reasons:

• An (IDEasy) project may have multiple code git repos (for many microservices) but want to have one IDE setup for the entire team
• On the other hand code git repos can grow big and it may take a long time to clone them (I have supported monolithic projects with multi million LOC where cloning alone takes more than 10 minutes). Getting an IDE change onto that git repo and testing it will be pure pain.
• We have the feature to configure code git repos in the settings-git repo so that you can get one or multiple code git repos cloned into various workspaces as needed by the project. This would all not make any sense if the settings are inside the code repo.
• So to summarize you currently have full flexibility: You can have 1 IDEasy project with 1 code repo, 1 IDEasy project with N code repos, N IDEasy projects with M code repos, etc. all in the same global development initiative.

Design

In order to support this new feature request, we should add an option to ide create that will tell that we are providing a git URL that is actually the code repo (e.g. ide create myproject --code https://git.company.com/domain/project.git[#branch]).
This will first create a $IDE_ROOT/myproject/workspaces/main/ and clone the code git repo into that folder.
Next IDEasy would verify that inside the cloned project there is a settings folder.
It will create a symlink $IDE_HOME/settings pointing to that settings folder.
All existing features to update our settings need to be modified since there will be no .git folder in $IDE_ROOT/settings and git fetch or git pull will not work there. Therefore ide update should skip the (alternatively the entire code git repo could be pulled, but I would leave that up to the end-user).
Further, we should track the git commit id (hash) of our settings.
Our feature to check for updates in settings should compare the current git commit id (determined from the root code git repo if settings is a symlink) with the tracked one. If the commit id does not match there are changes and the user should be informed that he may want to call ide update. This is also a helpful improvement if the regular and recommended settings git repo approach is used. If the end user manually calls git pull in settings, then IDEasy is not updated unless ide update is called but the user is not notified that updates are available (compare story #161). At the end of ide update process the git revision hash needs to be updated in the tracking file (e.g. a simple text file containing the revision let say in $IDE_ROOT/.settings.id).
On the other hand, if the git commit id is unchanged and nothing could be pulled from settings, we might know that the user is quite up-to-date (except for version patterns where new updates are available now).

Acceptance criteria

• IDEasy still works with a regular settings git repository
• after ide create or ide update the $IDE_ROOT/.settings.id is updated with the current commit id of the git repository hosting our settings (may be from a symlinked code-repo)
• if the current git commit id behind the settings repo differes from the tracked one (see above) the user gets the existing notification that changes are available and ide update should be called.
• https://github.com/devonfw/IDEasy/blob/main/documentation/settings.adoc has been updated with the description of this feature
• ide help create shows additional information about the feature and new options that have been added
• If I create a a git repo with a settings folder containing the current content of the ide-settings repo and some additional files (e.g. a README.adoc and something like src/test.txt and I call ide create test-code-settings --code https://«url-to-that-created-repo» then I can create an IDEasy project test-code-settings just like it would have been created using ide create test-code-settings -. However, in $IDE_ROOT/test-code-settings/workspaces/main/ I can find my repo cloned and $IDE_ROOT/test-code-settings/settings is a link pointing to the settings folder inside that cloned git repo inside main workspace.
• In case I later push an update to that git repo (e.g. change of MVN_VERSION in settings/ide.properties) and I pull these changes in the clode in main workspace and then 1. if I call a command like ide help, I can see that updates of settings are available and when I call ide update the new MVN_VERSION is applied and maven gets updated accordingly.
• the message Updates are available for the settings repository. If you want to pull the latest changes, call ide update. has been changed to Updates are available for the settings repository. If you want to apply the latest changes, call "ide update".

Discussion

We can even think about auto-detecting this and omitting the --code option.
If we clone our settings to $IDE_ROOT/settings and detect that our expected settings-structure is not directly inside but in a settings subfolder, we could then move the settings folder to the main workspace and and rename it to the name of the project that was contained in the git URL, create the symlink, etc.
Maybe this will prevent errors since the average user cannot make mistakes.