v2.3.1

What's Changed

• Improve label name and description validation by @srealmoreno in #172

New Contributors

• @srealmoreno made their first contribution in #172

Full Changelog: v2.3.0...v2.3.1

v2.3.0

What's Changed

• This release introduces an optional delete flag for labels. When true, matching labels will always be deleted. Feature by @LiSmi in #183

New Contributors

• @danielwerg made their first contribution in #174
• @LiSmi made their first contribution in #183

Full Changelog: v2.2.0...v2.3.0

v2.2.0: 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.

v2.1.1: 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.

v2.1.0: 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.

v2.0.2

Coerce color to String

patch: Fix label renaming regression

v2.0.1

fix test to expect new_name

major: Require latest node lts (12)

v2.0.0

Require latest node lts (12) (#66)

minor: Remove whitesource config

We haven't used whitesource for a year or more

v1.5.0: Add support for supplying multiple label files

- Fixes #49

This change introduces support for any number of `--labels` arguments to
be supplied. The behavior is the same as before, with regards to http(s)
urls or local paths, and after they are all collected, they will be
merged. Any items with a duplicate name and different property values
will throw an error. Otherwise they will be merged and then applied.