#1695: Clone settings to temporary directory, analyse, and then move

[laim2003]

This PR fixes #1695

Implemented changes:

• When creating a new project (or updating a project with a broken settings directory), the settings or code-settings directory passed through ide create projectname <<git-url>> is pulled to a temporary directory. There, we check whether the repository is a valid settings or code-settings repository and if the check succeeds, we move it to the final location depending on the repo type (and symlink in case of a code-settings repo).
• Removed the --code flag of ide create as we now automatically detect the type of the repository.

---

Testing instructions

Please add conscise, understandable instructions on how a reviewer can test/verify the functionality of your contribution here:

1. Checkout the state of this PR.

Create commandlet

3. Run ide create using the configurable running executions in intellij, so you dont accidentally test the create commandlet from the latest release, but the state from this PR. For the parameters: Pick a random project name. For the git-url parameter see below:
4. Try once using the default settings repo. In this case, check if a new project has been created, which has the settings repo contents correctly placed under IDE_HOME/settings. The creation should succeed!
5. Try once using a code-settings-mixed repo. As a git url, you can use: https://github.com/laim2003/code-settings-repo. The creation should succeed. Important: in the IDE_HOME project folder, a symlink with the name "settings" should be created. It should correctly point to the folder: IDE_HOME/workspaces/main/[repository name, in our case "code-settings-repo"]/settings
6. Try once using an invalid repository, for example, the default devonfw/IDEasy repository (this one is neither a settings or a code-settings repository). The project creation should now fail with an error message! Also, the creation process should not continue after the error!

Update commandlet

In order to test the update commandlet, you need to create your own settings repository.

1. On GitHub, create a new repository and during the creation process, when GitHub prompts you (normally the first step), select the devonfw/ide-settings template.
2. Run the ide create commandlet (again with the IntelliJ run configuration) and as the git-url use your newly created settings repo. It should succeed normally.
3. After that succeeded, make an edit to the settings repo. You can do that directly on GitHub (do not make that edit in your settings repo locally, this is important to test the functionality!). For example, update the ide.properties and change the NODE_VERSION=v18* to v23*, and commit the changes.
4. Now locally, in the newly created project, try running a commandlet, for example ide eclipse.
5. It is important to now check that the console prints "Updates are available for the settings repo".
6. Run ide update (again, using the run configuration in intellij), it should succeed.
7. As a final test, now delete the contents of your settins folder in your newly created project.
8. Now, run ide update again. It should detect the empty folder and prompt you to input a new Git Url. You can use the same URL you used before. This step should also succeed.

---

Checklist for this PR

Make sure everything is checked before merging this PR. For further info please also see
our DoD.

• When running mvn clean test locally all tests pass and build is successful
• PR title is of the form #«issue-id»: «brief summary» (e.g. #921: fixed setup.bat and not feature/921 fixed setup.bat). If no issue ID exists, title only.
• PR top-level comment summaries what has been done and contains link to addressed issue(s)
• PR and issue(s) have suitable labels
• Issue is set to In Progress and assigned to you or there is no issue (might happen for very small PRs)
• You followed all coding conventions
• You have added the issue implemented by your PR in CHANGELOG.adoc unless issue is labelled
  with internal
• You have not changed any dependency in pom.xml files or otherwise if runtime dependencies changed, you have updated our LICENSE.asciidoc
• You have formulated clear instructions on how to test your contribution under "Testing instructions"

[coveralls]

Coverage Report for CI Build 32034542201

Warning

No base build found for commit 31dabbf on main.
Coverage changes can't be calculated without a base build.
If a base build is processing, this comment will update automatically when it completes.

Coverage: 72.824%

Details

• Patch coverage: No coverable lines changed in this PR.

Uncovered Changes

No uncovered changes found.

Coverage Regressions

Requires a base build to compare against. How to fix this →

---

Coverage Stats

Relevant Lines:	17564
Covered Lines:	13343
Line Coverage:	75.97%
Relevant Branches:	7760
Covered Branches:	5099
Branch Coverage:	65.71%
Branches in Coverage %:	Yes
Coverage Strength:	3.23 hits per line

---

💛 - Coveralls

[laim2003]

Maybe it makes sense that the same way we use a new step for cloning the settings repo in general, in order to create a better user experience, we should also use a new step for the integrity check here? So it shows up as a separate step in the CLI? Just a thought.

[hohwille]

@laim2003 thanks for taking over and bringing this on the right track. 👍
I already left some comments to give early feedback since this story was already in end-review at least twice and we are turning in too many circles.
Please also note that if ide create fails then also no project shall even be created what is currently not the case.
My idea for this was that the update of the settings would be changed such that it returns a more complex result object that allows us to represent the following states:

• settings were already present and are valid (and maybe have been successfully updated)
• settings were cloned to temporary directory and are valid
• in all cases the information what type of repository we have (as RepositoryType).

Other cases currently lead to an exception but could also be represented in that state if we prefer to take control of throwing exception outside.

Then the operation to move a potential temporary settings or "code with settings" repo to the right place can be in a separate method.
This allows the update flow to call both methods sequentially but the create flow to call the first one initially, then if that succeeded actually create the project and populate it, updating the context and only then call the 2nd method to move the repo into the right place.
Does that make sense or do you have a better idea?

[hohwille]

Do we really want to rethrow here?
This will make the process fail if any kind of exception is happening in updateSettingsInStep like e.g. "git pull" fails due to error of custom git server.
Currently I can still continue installing software updates then.
This will change now.
IMHO you want to archive that the further processing stops and fails if specific guardrails did not meet like the settings repo could not be cloned or it is not containing any settings.
Thinking this over and digging into step.run implementation, I would suggest the following:

• Currently we either handle or re-throw all exceptions there.
• I would suggest to add a method CliException.isForceRethrowInStep() that by default returns false.
• Extend implementation of step.run to also consider this method so we always re-throw in case that method returns true.
• Create a CliRethrowException (or CliFatalException) that overrides this new method returning true.
• Explicitly throw this new exception in updateSettingsInStep if no valid settings could be established.

BTW: We could even consider (in a separate PR if CliAbortException should also cause this effect (of isForceRethrowInStep()).

[hohwille]

It would be safer to use FileAccess.createTempDir that guarantees us to produce a unique empty directory.
Otherwise you should ensure the directory is empty and not some leftover from a previous try is still present there (FileAccess.delete followed by FileAccess.mkdirs).

[hohwille]

Use JavaDoc instead of inline comment.

Suggested change

	/// Utility class for IDEasy settings/code repositories
	/** Utility class for IDEasy settings/code repositories. */

[hohwille]

Couldn't this unconstrainted recursion lead to accepting stuff like settings/settings/ide.properties?
I would at least ensure we do not run into recursion again:

Suggested change

	} else if (gitProjectName != null
	&& Files.exists(repositoryPath.resolve(IdeContext.FOLDER_SETTINGS))
	&& getRepositoryType(repositoryPath.resolve(IdeContext.FOLDER_SETTINGS), gitProjectName) == RepositoryType.SETTINGS) {
	return RepositoryType.CODE_SETTINGS_COMBINED;
	} else if (gitProjectName != null
	&& Files.exists(repositoryPath.resolve(IdeContext.FOLDER_SETTINGS))
	&& getRepositoryType(repositoryPath.resolve(IdeContext.FOLDER_SETTINGS), null) == RepositoryType.SETTINGS) {
	return RepositoryType.CODE_SETTINGS_COMBINED;

[hohwille]

1. also here use JavaDoc instead of inline comments (BTW: inline comments in Java only have 2 slashes not 3).
2. in general avoid nested types. It fully makes sense to have this enum as a top-level type in its own class. Esp. since it is used outside of this RepositoryUtil.