Tags: Financial-Times/github-label-sync
Tags
Add support for label merge There are two scenarios where handling a label configuration would require merging one label into another: - The configured label exists in the current labels and its alias exists in the current labels - Multiple aliases of a configured label exist in the current labels Previously, "GitHub Label Sync" did not have support for label merge, and would return an error when the user's configuration would have required a merge operation. The merge capability is added here. The GitHub labels API does not provide a merge capability, so merging labels requires the use of the issues API to add the "expected" label to each issue/PR that has the "actual" label. From the user's perspective, the outcome of this "merge" operation is no different from any simple "changed" operation: the "actual" label has been replaced by the "expected" label in the repository labels and all issues/PRs the label was applied to.
Communicate lack of support for label merge There are two scenarios where handling a label configuration would require merging one label into another: - The configured label exists in the current labels and its alias exists in the current labels - Multiple aliases of a configured label exist in the current labels As an attempt to work around the lack of a merge capability, "GitHub Label Sync" arbitrarily selects the first current label matching the configuration for processing and silently ignores the other matching labels. Under specific conditions, the workaround does as intended. Under other conditions, even the single matching current label it deigned to recognize would require a merge. Since it is treated as a normal "changed" entry, the attempt to change the name of the current label to the name of another current label is rejected by the GitHub API with a cryptic "422: Validation Failed" error, since it does not support merging labels in this manner. Neither behavior (silently ignoring a configuration or failing cryptically) provides a good user experience. The ideal would be to provide the required merge capability. Second best is to clearly communicate the situation to the user. The latter is implemented here. When a configuration requires a merge, GitHub Label Sync prints a clear error message identifying the problematic configuration element(s) and exits with status 1. The repository maintainer can then manually adjust the unsupported labels in order to begin using "GitHub Label Sync" successfully. This is done by adding a new "merge" diff entry type, which also lays the groundwork for the addition of a merge capability.
Record all current label matches as resolved There are two scenarios where multiple current labels can match a configured label: - The configured label exists in the current labels and an alias exists in the current labels - Multiple aliases of the configured label exist in the current labels As a partial workaround for the lack of a label merge capability in GitHub Label Sync, only the first matching label is processed for the creation of a diff entry. This approach was mistakenly applied also to adding matches to the list of "resolved" labels. That caused the tool to think that any additional matching labels did not match any label configuration, which resulted in "added" entries being created for them, and their incorrect deletion in the default mode where additional labels are not allowed.
PreviousNext