All Projects β†’ mattermost β†’ chewbacca

mattermost / chewbacca

Licence: Apache-2.0 license
Chewbacca GitHub Bot

Programming Languages

go
31211 projects - #10 most used programming language
HTML
75241 projects
Makefile
30231 projects
shell
77523 projects
Dockerfile
14818 projects
CSS
56736 projects

Projects that are alternatives of or similar to chewbacca

aloba
πŸ€– [Myrmica Aloba 🐜] Bot: Add labels and milestone on pull requests and issues.
Stars: ✭ 18 (+12.5%)
Mutual labels:  github-bot
github-rebase-bot
A github bot that monitors repository PRs, rebases them and merges them as they pass tests
Stars: ✭ 29 (+81.25%)
Mutual labels:  github-bot
BastionGitHubBot
πŸš€ A GitHub bot to automate common tasks in GitHub.
Stars: ✭ 15 (-6.25%)
Mutual labels:  github-bot
github-bot
This is a github bot that helps with managing issues, used on
Stars: ✭ 29 (+81.25%)
Mutual labels:  github-bot
triage-new-issues
A GitHub App, built with Probot that adds `triage` label to newly-created issues which don't have labels
Stars: ✭ 23 (+43.75%)
Mutual labels:  github-bot
thearesia
Github bot built with Rust
Stars: ✭ 17 (+6.25%)
Mutual labels:  github-bot
issuelabeler
A GitHub bot to label issues automatically based on title and body against list of defined labels. System status (https://status.verticalaxisbd.com/)
Stars: ✭ 23 (+43.75%)
Mutual labels:  github-bot
github-clear-merged-pull-requests
Clear merged pull requests ref (branch) on GitHub
Stars: ✭ 12 (-25%)
Mutual labels:  github-bot
watchdog
DEPRECATED -- Github Bot for Datadog codification
Stars: ✭ 26 (+62.5%)
Mutual labels:  github-bot
check-in
Checks your test results metadata into github, commit-bound. Acts as a bot. You'll need a GitHub App to use it.
Stars: ✭ 18 (+12.5%)
Mutual labels:  github-bot
telegram-github-search-bot
A Github search bot for Telegram
Stars: ✭ 67 (+318.75%)
Mutual labels:  github-bot
sign-off-checker
A GitHub integration to ensure commits have "Signed-off-by"
Stars: ✭ 34 (+112.5%)
Mutual labels:  github-bot
performabot
Continuous performance analysis reports for software projects πŸ€–
Stars: ✭ 40 (+150%)
Mutual labels:  github-bot
background-check
A GitHub App built with probot that peforms a "background check" to identify users who have been toxic in the past, and shares their toxic activity in the maintainer’s repo.
Stars: ✭ 27 (+68.75%)
Mutual labels:  github-bot
container-builder-github-ci-status
Google Cloud Function responds to PubSub events on the cloud-builds topic to update GitHub CI status.
Stars: ✭ 23 (+43.75%)
Mutual labels:  github-bot
dx-automator
A tool for managing priorities across multiple GitHub repositories
Stars: ✭ 14 (-12.5%)
Mutual labels:  github-bot
lobicornis
πŸ€– [Myrmica Lobicornis 🐜] Bot: Update and Merge Pull Request
Stars: ✭ 27 (+68.75%)
Mutual labels:  github-bot
scalafmt-probot
πŸ€–Github bot for checking code formatting with scalafmt
Stars: ✭ 15 (-6.25%)
Mutual labels:  github-bot
Hamster
πŸ€ A Bot toolkit for github that supports OAuth, Events, API, Custom Commands and Check Runs.
Stars: ✭ 40 (+150%)
Mutual labels:  github-bot
zorechka-bot
Github bot for keeping your Bazel dependencies up-to-date and clean
Stars: ✭ 25 (+56.25%)
Mutual labels:  github-bot

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.

labels:
- name: do-not-merge
  description: Should not be merged until this label is removed
  color: a32735
- name: do-not-merge/awaiting-PR
  description: ""
  color: a32735
- name: do-not-merge/release-note-label-needed
  description: ""
  color: e11d21
- name: do-not-merge/work-in-progress
  description: ""
  color: a32735
- name: do-not-merge/awaiting-submitter-action
  description: Blocked on the author
  color: e11d21
- name: kind/api-change
  description: Categorizes issue or PR as related to adding, removing, or otherwise
    changing an API
  color: e11d21
- name: kind/bug
  description: Categorizes issue or PR as related to a bug.
  color: e11d21
- name: kind/cleanup
  description: Categorizes issue or PR as related to cleaning up code, process, or
    technical debt.
  color: c7def8
- name: kind/deprecation
  description: Categorizes issue or PR as related to a feature/enhancement marked
    for deprecation.
  color: e11d21
- name: kind/design
  description: Categorizes issue or PR as related to design.
  color: c7def8
- name: kind/documentation
  description: Categorizes issue or PR as related to documentation.
  color: c7def8
- name: kind/feature
  description: Categorizes issue or PR as related to a new feature.
  color: c7def8
- name: kind/regression
  description: Categorizes issue or PR as related to a regression from a prior release.
  color: e11d21
- name: priority/critical-urgent
  description: Highest priority. Must be actively worked on as someone's top priority
    right now.
  color: e11d21
- name: priority/important-longterm
  description: Important over the long term, but may not be staffed and/or may need
    multiple releases to complete.
  color: eb6420
- name: priority/important-soon
  description: Must be staffed and worked on either currently, or very soon, ideally
    in time for the next release.
  color: eb6420
- name: release-note
  description: Denotes a PR that will be considered when it comes time to generate
    release notes.
  color: c2e0c6
- name: release-note-action-required
  description: Denotes a PR that introduces potentially breaking changes that require
    user action.
  color: c2e0c6
- name: release-note-none
  description: Denotes a PR that doesn't merit a release note.
  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

    <!-- Thank you for contributing a pull request! Here are a few tips to help you:

    1. If this is your first contribution, make sure you've read the Contribution Checklist https://developers.mattermost.com/contribute/getting-started/contribution-checklist/
    2. Read our blog post about "Submitting Great PRs" https://developers.mattermost.com/blog/2019-01-24-submitting-great-prs
    3. Take a look at other repository specific documentation at https://developers.mattermost.com/contribute
    -->

    #### Summary
    <!--
    A description of what this pull request does.
    -->

    #### Ticket Link
    <!--
    If this pull request addresses a Help Wanted ticket, please link the relevant GitHub issue, e.g.

      Fixes https://github.com/mattermost/mattermost-server/issues/XXXXX

    Otherwise, link the JIRA ticket.
    -->

    #### Release Note
    <!--
    If no, just write "NONE" in the release-note block below.
    If yes, a release note is required:
    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".

    -->

    ```release-note

    ```

Release Notes process

Does my pull request need a release note?

Any user-visible or operator-visible change qualifies for a release note. This could be a:

  • CLI change
  • API change
  • UI change
  • configuration schema change
  • behavioral change
  • change in non-functional attributes such as efficiency or availability, availability of a new platform
  • a warning about a deprecation
  • fix of a previous Known Issue
  • fix of a vulnerability (CVE)

No release notes are required for changes to:

  • tests
  • build infrastructure
  • fixes of bugs which have not been released

Contents of a Release Note

A release note needs a clear, concise description of the change. This includes:

  1. an indicator if the pull request Added, Changed, Fixed, Removed, Deprecated functionality or changed enhancement/feature maturity (alpha, beta, stable/GA)
  2. an indicator if there is user Action required
  3. the name of the affected API or configuration fields, CLI commands/flags or enhancement/feature
  4. a link to relevant user documentation about the enhancement/feature

Applying a Release Note

To meet this requirement, do one of the following:

  • Add notes in the release notes block, or
  • Update the release note label

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.

To add a release-note section to the pull request description:

For pull requests with a release note:

```release-note
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:

```release-note
action required: your release note here
```

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:

```release-note
NONE
```

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

Note that the project description data, including the texts, logos, images, and/or trademarks, for each open source project belongs to its rightful owner. If you wish to add or remove any projects, please contact us at [email protected].