ENH: Add a script to apply another script to all remotes

[jhlegarreta]

Add a script to apply another script to all remotes.

This script is intended to ease the extension of toolkit-wide changes that
are applied through a bash script to the remote modules that dwell in/are
referenced from the toolkit's Modules/Remote module.

PR Checklist

• Makes breaking changes
• Makes design changes
• Adds the License notice to new files.
• Adds Python wrapping.
• Adds tests and baseline comparison (quantitative).
• Adds test data.
• Adds Examples to ITKExamples
• Adds Documentation.

Refer to the ITK Software Guide for
further development details if necessary.

[jhlegarreta]

Completing all CMake configuration steps is not necessary, so should we just extract (if that is possible) the relevant parts from the CMakeLists.txt to clone the remotes in the ITK source tree?

[jhlegarreta]

Removed files are not added to the commit.

Otherwise, we could assume that a git add . could be done since it will be a new branch, with no files and changes other than those applied by the script.

[jhlegarreta]

• Rather that keeping the remote URLs from the list_candidate_remotes function, I do get the URL again in apply_script_and_push_remotes. I though it was easier than keeping a list from the former method, then finding the appropriate element for the remote at issue (partly because the URL includes the username and password for the push to be done). If you feel there is an alternative to this, please go ahead.

[jhlegarreta]

The full path of the script to be applied must be provided. Otherwise, we could assume that only scripts that dwell in Utilities will be applied, since they anyways will be worthwhile maintaining there for the records and for the sake of our philosophy.

[jhlegarreta]

The commit message must be provided explicitly. Many of the ITKv5 preparation scripts do it all at once: do the changes, add them and commit with a message contained in the script itself.

We should consider whether we prefer that the add and commit steps will generally be contained in the script that is applied.

[jhlegarreta]

As discussed some time ago by mail. Took me a while to gather some time to do it, but here it goes.

Just as a reminder, this script can be used to apply changes such as the ones done for the ITKv5 preparation, or changes like removing the AppVeyor, Circle CI, and Travis CI files and adding the azure-pipelines.yml configuration, updating the README.rst files accordingly, etc., changes that may be related to C++14, 17 or 20, etc.

A few thoughts in-line, and other additional ones (some may require careful consideration, and further work, so we should assume it will not be immediate to answer/address them):

• We can rename the script if we find it is not too descriptive.
• We can change the help message formatting if it is not too bash script-like.
• The script does a direct push to the ISC organization repository, and thus assumes the user is part of the organization.
• Linked to the above, no upstream remote is configured. As we do usually with ITK, may be it would more orthodox to configure the origin and upstream, assume the user has all remotes forked, and push to their fork (I have not tested push step).
• Not sure about the behavior of the script if a few remotes have already been cloned, have local untracked or uncommitted changes, etc. This should be considered at some point.
• The script assumes that a local branch with the same name as the one provided as the feature branch does not exist. Should we remove it in case it exists?
• The script assumes that a remote branch with the same name as the one provided as the feature branch does not exist. Should we push force in case it exists?
• Remote modules that are checked out are not deleted from the ITK source tree. Should we delete them? I'd dare to say that if yes, we should handle the case where some remotes had already been cloned and had untracked, uncommitted, local branches, etc.

Many of the branch collision cases are covered by @fbudin69500 's Slicer 3D extensions script. So it could be of help.

Once these aspects fixed, we could think of updating the UpdateRequiredITKVersionInRemoteModules.sh so that given the remote module name, it updates the azure-pipelines.yml and setup.py files automatically (provided that the former is always at the same location).

@maekclena This is related to the remote module maintenance script, so you may want to have a look/improve it. Thanks.

[hjmjohnson]

LGTM

[jhlegarreta]

Thanks Hans. The PR had a few unresolved comments and requests for comment, but I think it is fine. We will improve it as we use it.