Managing Split Repositories ¶
A special feature of HuPKit is the ability to handle monolith project developments, instead of having separate Git repositories for each package, all are housed in a central repository from where all work is coordinated.
Note
Before you continue make sure splitsh-lite is installed and can be
found in your PATH
environment (no shell alias!).
Configuration ¶
To make this "repository splitting" work, a number of targets must be configured. Each target consists of a prefix (directory path), target repository and some additional options like if tag-synchronizing is enabled.
Tip
Suffice to say, the split target repositories must exist!
They are not created automatically, but you can use the split-create
command to create the repositories, any already existing ones are ignored,
missing ones created.
See Repository splitting configuration, how to configure your splits.
To test if the configuration is correct run the split-repo --dry-run
command to see what would have happened.
Everything correct? Then run the split-repo
command.
Note
Depending on the total amount of commits, split targets, and your internet speed, this process might take some time to complete.
Splitting After a Pull Request Merge ¶
Once the repository splitting is configured, you want to make sure the split repositories are up-to-date.
You can either run the split-repo
command at any time, or split
the repository after you merge a pull request,
this process may take some time depending of number of commits and targets.
Tip
If you need to merge more than one pull-request you'd properly want to hold-of the split operation until you're done.
Use no-split
command option to skip the splitting, or set the
pull_request.split
repository configuration to none
.
Caution
Splitting is automatically skipped when the --no-pull
command option
is provided.
Splitting With a Release ¶
The release
command works a little different here. When making a new release the
split operation is always performed! You cannot skip this. However you can skip
the synchronizing of tags for certain split repositories by setting the sync-tags
config to false.
1 2 3 4 5 6 7 8 9 10 11 12 13 |
return [
'branches' => [
':default' => [
'sync-tags' => true, // disable for all (or...)
'split' => [
// Disable/enable per repository target
'src/Bundle/CoreBundle' => ['url' => 'git@github.com:park-manager/core-bundle.git', 'sync-tags' => true],
],
],
// ...
],
];
|
Existing tags in split repositories are always ignored.
Changed-only Releases ¶
By default a new release will create tags for all split targets, but it's possible to ignore creating tags for split targets which haven't changed since the last release.
Note
All split targets still use the version increments of the monolith repository.
It's not possible to have package B with a different versioning when synchronizing of tags (for the target) is still enabled.
1 2 3 4 5 6 7 8 9 |
return [
// ...
'release' => [
'split' => 'changed-only',
// ...
],
];
|