This is not intended to be a comprehensive test suite; I'm just trying to get us started by adding tests for some of the most important functionality.
This necessitated some minor refactoring. Previously, `main.ts` just directly invoked the main entrypoint function `run()`, which made it impossible to unit test the module without causing the side-effects of `run`.
As a workaround I created a new module `labeler.ts`, which just exports the functions we want to test without executing the main entrypoint, and simplified `main.ts` so that it only imports the entrypoint and executes it.
It's basically just a re-org. The diff makes it look way more complicated than it is.
- Document the release process in `CONTRIBUTING.md`
- Add development instructions to `CONTRIBUTING.md` (adapted from [download-artifact](https://github.com/actions/download-artifact))
- Add a test badge to the `README`
- Link to `CONTRIBUTING.md` in `README`
- Unify copy between `README.md` and `action.yml`
- Copy-pasta the CoC from [download-artifact](https://github.com/actions/download-artifact)
* Draft contributors.md update
This is a proposed updated to the contributors.md document inspired by
the contributing guidelines of the actions/cache project [1]. There are
some differences, most notable the inclusion of "Development Details"
which explains and motivates the development tools (to an extend).
--
1. https://github.com/actions/cache/blob/eed9cfe64d00dd64cbb36bec915d41dd6fab9f6c/CONTRIBUTING.md
* Split Contributing Guidelines and Development Handbook
Split the "Contributing Guidelines" currently found in
docs/contributors.md into a CONTRIBUTING.md file, containing the
Contributing Guidelines, and a docs/development.md file, containing
details on how the development/testing of this project works.
The previous logic had a bug where the "any" pattern list could match
against changed files even when not all globs matched a single changed
file. The bug arose individual globs in the "any" list were tested
against all changed files individually. Therefore, as long as at least
one changed file matched an individual glob in the list, a successful
match would be found.
The correct behavior is to match all the globs in the list against each
individual file. This ensures that is possible to define exlcusions
correctly and matched the documented behavior.
* Add support for exclusions
Paths can be negated to stop searching through the remaining patterns in
a the glob list. All changed files tested and at least one matching file
will result in a label being added.
Fixesactions/labeler#9
* Add support for "AND"-ed matches
A new "rich" matcher object can be provided instead of a normal glob.
The matcher object has two fields that accept an array of globs:
* Globs in "all" must all match every changed file.
* Globs in "some" must all match at least one changed file.
Combined with negated globs, this allows for a precise control of when
labels are applied.
* Rename `some` to `any`
* Update README
