项目作者: mattermost

项目描述 :
Chewbacca GitHub Bot
高级语言: Go
项目地址: git://github.com/mattermost/chewbacca.git
创建时间: 2020-04-22T07:20:56Z
项目社区:https://github.com/mattermost/chewbacca

开源协议:Apache License 2.0

下载


Chewbacca - Github Bot

Chewbacca born to help us at Mattermost when need to interact with GitHub.
The name Chewbacca was choosen because Chewbacca in Star Wars movies help everybody and this bot will help us :-)

Chewbacca is helping today to check and set labels related to release notes. The code was fork from some plugins from https://github.com/kubernetes/test-infra/tree/master/prow which is an awesome Bot for Kubernetes community.

Installation

To install you can deploy the manifests in the kubernetes folder.
But before that please change the secret manifest to add your own secrets and also the ingress manifest to add your own domain.

When this is running you can set your GitHub repo to send the webhooks for Chewbacca, this bot need only issue_comments and pull_request events for now.

Also is good to set, at least, those labels in your repo.

  1. labels:
  2. - name: do-not-merge
  3. description: Should not be merged until this label is removed
  4. color: a32735
  5. - name: do-not-merge/awaiting-PR
  6. description: ""
  7. color: a32735
  8. - name: do-not-merge/release-note-label-needed
  9. description: ""
  10. color: e11d21
  11. - name: do-not-merge/work-in-progress
  12. description: ""
  13. color: a32735
  14. - name: do-not-merge/awaiting-submitter-action
  15. description: Blocked on the author
  16. color: e11d21
  17. - name: kind/api-change
  18. description: Categorizes issue or PR as related to adding, removing, or otherwise
  19. changing an API
  20. color: e11d21
  21. - name: kind/bug
  22. description: Categorizes issue or PR as related to a bug.
  23. color: e11d21
  24. - name: kind/cleanup
  25. description: Categorizes issue or PR as related to cleaning up code, process, or
  26. technical debt.
  27. color: c7def8
  28. - name: kind/deprecation
  29. description: Categorizes issue or PR as related to a feature/enhancement marked
  30. for deprecation.
  31. color: e11d21
  32. - name: kind/design
  33. description: Categorizes issue or PR as related to design.
  34. color: c7def8
  35. - name: kind/documentation
  36. description: Categorizes issue or PR as related to documentation.
  37. color: c7def8
  38. - name: kind/feature
  39. description: Categorizes issue or PR as related to a new feature.
  40. color: c7def8
  41. - name: kind/regression
  42. description: Categorizes issue or PR as related to a regression from a prior release.
  43. color: e11d21
  44. - name: priority/critical-urgent
  45. description: Highest priority. Must be actively worked on as someone's top priority
  46. right now.
  47. color: e11d21
  48. - name: priority/important-longterm
  49. description: Important over the long term, but may not be staffed and/or may need
  50. multiple releases to complete.
  51. color: eb6420
  52. - name: priority/important-soon
  53. description: Must be staffed and worked on either currently, or very soon, ideally
  54. in time for the next release.
  55. color: eb6420
  56. - name: release-note
  57. description: Denotes a PR that will be considered when it comes time to generate
  58. release notes.
  59. color: c2e0c6
  60. - name: release-note-action-required
  61. description: Denotes a PR that introduces potentially breaking changes that require
  62. user action.
  63. color: c2e0c6
  64. - name: release-note-none
  65. description: Denotes a PR that doesn't merit a release note.
  66. color: c2e0c6

To apply the labels in your repo you can edit manually or use a tool like https://github.com/cpanato/github-gitlab-labels

Pull request template

Also is good to set a Pull request template to add the release-note section. For that in your repo add the folder .github and a file called PULL_REQUEST_TEMPLATE.md

We are using this template

  1. <!-- Thank you for contributing a pull request! Here are a few tips to help you:
  2. 1. If this is your first contribution, make sure you've read the Contribution Checklist https://developers.mattermost.com/contribute/getting-started/contribution-checklist/
  3. 2. Read our blog post about "Submitting Great PRs" https://developers.mattermost.com/blog/2019-01-24-submitting-great-prs
  4. 3. Take a look at other repository specific documentation at https://developers.mattermost.com/contribute
  5. -->
  6. #### Summary
  7. <!--
  8. A description of what this pull request does.
  9. -->
  10. #### Ticket Link
  11. <!--
  12. If this pull request addresses a Help Wanted ticket, please link the relevant GitHub issue, e.g.
  13. Fixes https://github.com/mattermost/mattermost-server/issues/XXXXX
  14. Otherwise, link the JIRA ticket.
  15. -->
  16. #### Release Note
  17. <!--
  18. If no, just write "NONE" in the release-note block below.
  19. If yes, a release note is required:
  20. Enter your extended release note in the block below. If the PR requires additional action from users switching to the new release, include the string "action required".
  21. -->
  22. ```release-note
  1. ## Release Notes process
  2. ### Does my pull request need a release note?
  3. Any user-visible or operator-visible change qualifies for a release note. This
  4. could be a:
  5. - CLI change
  6. - API change
  7. - UI change
  8. - configuration schema change
  9. - behavioral change
  10. - change in non-functional attributes such as efficiency or availability,
  11. availability of a new platform
  12. - a warning about a deprecation
  13. - fix of a previous _Known Issue_
  14. - fix of a vulnerability (CVE)
  15. No release notes are required for changes to:
  16. - tests
  17. - build infrastructure
  18. - fixes of bugs which have not been released
  19. ### Contents of a Release Note
  20. A release note needs a clear, concise description of the change. This includes:
  21. 1. an indicator if the pull request _Added_, _Changed_, _Fixed_, _Removed_,
  22. _Deprecated_ functionality or changed enhancement/feature maturity (alpha,
  23. beta, stable/GA)
  24. 2. an indicator if there is user _Action required_
  25. 3. the name of the affected API or configuration fields, CLI commands/flags or
  26. enhancement/feature
  27. 4. a link to relevant user documentation about the enhancement/feature
  28. ### Applying a Release Note
  29. To meet this requirement, do one of the following:
  30. - Add notes in the release notes block, or
  31. - Update the release note label
  32. If you don't add release notes in the pull request template, the `do-not-merge/release-note-label-needed` label is added to your pull request automatically after you create it. There are a few ways to update it.
  33. To add a release-note section to the pull request description:
  34. For pull requests with a release note:
  35. ```release-note
  36. Your release note here

For pull requests that require additional action from users switching to the new release, include the string “action required” (case insensitive) in the release note:

  1. ```release-note
  2. action required: your release note here
  3. ```

For pull requests that don’t need to be mentioned at release time, use the /release-note-none Chewbacca command to add the release-note-none label to the PR. You can also write the string “NONE” as a release note in your PR description:

  1. ```release-note
  2. NONE
  3. ```

Reviewing Release Notes

Reviewing the release notes of a pull request should be a dedicated step in the
overall review process. It is necessary to rely on the same metrics as other
reviewers to be able to distinguish release notes which might need to be
rephrased.

As a guideline, a release notes entry needs to be rephrased if one of the
following cases apply:

  • The release note does not communicate the full purpose of the change.
  • The release note has no impact on any user.
  • The release note is grammatically incorrect.

In any other case the release note should be fine.

note: this was copy and adapt from kubernetes/community