Skip to content

v2.1.1: Communicate lack of support for label merge

Compare
Choose a tag to compare
@JakeChampion JakeChampion released this 30 Mar 10:37
· 19 commits to master since this release
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.