Runs commitlint against your projects PRs
5 |
24 |
25 |
26 | ## The problem
27 |
28 | You use [conventional-changelog](http://conventionalcommits.org/), but you squash pull requests (PRs). So you want PR titles to match the same semantics as your conventional changelog requirements. _(If you want a bot to lint against your commit messages instead of the PR title, then check out [ahmed-taj/commitlint-bot](https://github.com/ahmed-taj/commitlint-bot)!)_
29 |
30 | ## This solution
31 |
32 | commitlintbot is a bot that will update your pull request's commit status based on your PR's title satisfying the requirements of your conventional-changelog configuration. It runs on now.sh, and receives github webhooks and updates a commit status via the Github API.
33 |
34 |
35 | 
36 | 
37 |
38 |
39 | ## Configuration
40 | * A [default commitlint config](./default-commitlint.config.js) will be applied.
41 | - However if you have a `commitlint.config.js` in the root of the repo, that will be used instead. The other config formats (.commitlintrc.js, .commitlintrc.json, .commitlintrc.yml) are **not** supported.
42 | * Additionally, if you have a `.cz-config.js` in the root of your repo, that will be used to enforce your custom scopes & types.
43 |
44 |
45 | ## Installation
46 |
47 | * Setup webhook.
48 | * `https://commitlintbot2.vercel.app/api/lint-title`
49 | * `application/json`
50 | * Secret... not implemented. :|
51 | * Choose individual events: `Pull request`
52 | * Add.
53 | * If you want to use this in an organization and the org has fairly locked down permissions, org owners will need to approve the use of the app (via OAuth client_id): https://github.com/settings/connections/applications/e3737bbd21bc66fb0a18
54 |
55 | Now, things should be pretty automatic.
56 |
57 | ## Troubleshooting
58 |
59 | The responses of the webhook should be minimally helpful:
60 |
61 | 
62 |
63 |
64 | ## Dev
65 |
66 | ### getting a magical oauth token to use so the icon is the app not me
67 |
68 | 1. https://github.com/login/oauth/authorize?client_id=e3737bbd21bc66fb0a18&login=GoogleChrome&scope=repo:status%20public_repo
69 | 2. grab the `code` that's in the URL afterwards.
70 | 3. https://developer.github.com/apps/building-oauth-apps/authorizing-oauth-apps/#2-users-are-redirected-back-to-your-site-by-github
71 | * use postman or whatever to post those in the body
72 |
73 |
74 | ## LICENSE
75 |
76 | MIT
77 |
78 | [npm]: https://www.npmjs.com/
79 | [node]: https://nodejs.org
80 | [build-badge]: https://img.shields.io/travis/paulirish/commitlintbot/master.svg?style=flat-square
81 | [build]: https://travis-ci.org/paulirish/commitlintbot
82 | [coverage-badge]: https://img.shields.io/codecov/c/github/paulirish/commitlintbot.svg?style=flat-square
83 | [coverage]: https://codecov.io/github/paulirish/commitlintbot
84 | [version-badge]: https://img.shields.io/npm/v/commitlintbot.svg?style=flat-square
85 | [package]: https://www.npmjs.com/package/commitlintbot
86 | [downloads-badge]: https://img.shields.io/npm/dm/commitlintbot.svg?style=flat-square
87 | [npmtrends]: http://www.npmtrends.com/commitlintbot
88 | [license-badge]: https://img.shields.io/npm/l/commitlintbot.svg?style=flat-square
89 | [license]: https://github.com/paulirish/commitlintbot/blob/master/LICENSE
90 | [prs-badge]: https://img.shields.io/badge/PRs-welcome-brightgreen.svg?style=flat-square
91 | [prs]: http://makeapullrequest.com
92 | [donate-badge]: https://img.shields.io/badge/$-support-green.svg?style=flat-square
93 | [coc-badge]: https://img.shields.io/badge/code%20of-conduct-ff69b4.svg?style=flat-square
94 | [coc]: https://github.com/paulirish/commitlintbot/blob/master/other/CODE_OF_CONDUCT.md
95 | [github-watch-badge]: https://img.shields.io/github/watchers/paulirish/commitlintbot.svg?style=social
96 | [github-watch]: https://github.com/paulirish/commitlintbot/watchers
97 | [github-star-badge]: https://img.shields.io/github/stars/paulirish/commitlintbot.svg?style=social
98 | [github-star]: https://github.com/paulirish/commitlintbot/stargazers
99 | [twitter]: https://twitter.com/intent/tweet?text=Check%20out%20commitlintbot%20by%20%40paulirish%20https%3A%2F%2Fgithub.com%2Fpaulirish%2Fcommitlintbot%20%F0%9F%91%8D
100 | [twitter-badge]: https://img.shields.io/twitter/url/https/github.com/paulirish/commitlintbot.svg?style=social
101 | [emojis]: https://github.com/paulirish/all-contributors#emoji-key
102 | [all-contributors]: https://github.com/paulirish/all-contributors
103 |
--------------------------------------------------------------------------------
/__tests__/index.js:
--------------------------------------------------------------------------------
1 | const commitlintbot = require('../src/index');
2 |
3 | test.skip('commitlint should not throw', async () => {
4 | const prData = {
5 | "repo": "paulirish/hello-world",
6 | "srcRepo": "paulirish/hello-world",
7 | "sha": "0b1071e273a63bdaa3b477aeafbb585247de3cbb",
8 | "pr": 7
9 | };
10 |
11 | expect(commitlintbot).toBeDefined();
12 |
13 | const fullRun = await commitlintbot(prData);
14 | expect(fullRun).toBeUndefined();
15 | })
16 |
--------------------------------------------------------------------------------
/__tests__/lint.js:
--------------------------------------------------------------------------------
1 | const lint = require('../src/lint');
2 |
3 | test('commitlint should work', async () => {
4 |
5 | expect(lint).toBeDefined();
6 |
7 | let ret = await lint('fix: ok');
8 | expect(ret.reportObj.valid).toEqual(true);
9 |
10 | ret = await lint('no type or message because no colon');
11 | expect(ret.reportObj.valid).toEqual(false);
12 | expect(ret.reportObj.errors.length).toEqual(2);
13 |
14 | ret = await lint('nondefaulttype: wont work');
15 | expect(ret.reportObj.valid).toEqual(false);
16 | expect(ret.reportObj.errors.length).toEqual(1);
17 | });
18 |
19 | // todo add tests for handling czConfig
20 |
--------------------------------------------------------------------------------
/api/details.js:
--------------------------------------------------------------------------------
1 |
2 |
3 | const viewDetails = require('../src/server').viewDetails;
4 |
5 | export default viewDetails;
6 |
--------------------------------------------------------------------------------
/api/hello.js:
--------------------------------------------------------------------------------
1 |
2 | module.exports = (req, res) => {
3 | const { name = 'World' } = req.query
4 | res.send(`Hello ${name}!`)
5 | }
6 |
--------------------------------------------------------------------------------
/api/lint-title.js:
--------------------------------------------------------------------------------
1 |
2 |
3 | import {indexPOST} from '../src/server.js';
4 |
5 | export default indexPOST;
6 |
7 |
--------------------------------------------------------------------------------
/now.json:
--------------------------------------------------------------------------------
1 | {
2 | "version": 2,
3 | "scope": "paulirish",
4 | "alias": "commitlintbot2",
5 | "files": [
6 | "src",
7 | "api",
8 | "yarn.lock",
9 | ".gitignore",
10 | ".gitattributes"
11 | ],
12 | "env": {
13 | "ghtoken":"@ghtoken"
14 | }
15 | }
--------------------------------------------------------------------------------
/other/CODE_OF_CONDUCT.md:
--------------------------------------------------------------------------------
1 | # Contributor Covenant Code of Conduct
2 |
3 | ## Our Pledge
4 |
5 | In the interest of fostering an open and welcoming environment, we as
6 | contributors and maintainers pledge to making participation in our project and
7 | our community a harassment-free experience for everyone, regardless of age, body
8 | size, disability, ethnicity, gender identity and expression, level of experience,
9 | nationality, personal appearance, race, religion, or sexual identity and
10 | orientation.
11 |
12 | ## Our Standards
13 |
14 | Examples of behavior that contributes to creating a positive environment
15 | include:
16 |
17 | * Using welcoming and inclusive language
18 | * Being respectful of differing viewpoints and experiences
19 | * Gracefully accepting constructive criticism
20 | * Focusing on what is best for the community
21 | * Showing empathy towards other community members
22 |
23 | Examples of unacceptable behavior by participants include:
24 |
25 | * The use of sexualized language or imagery and unwelcome sexual attention or
26 | advances
27 | * Trolling, insulting/derogatory comments, and personal or political attacks
28 | * Public or private harassment
29 | * Publishing others' private information, such as a physical or electronic
30 | address, without explicit permission
31 | * Other conduct which could reasonably be considered inappropriate in a
32 | professional setting
33 |
34 | ## Our Responsibilities
35 |
36 | Project maintainers are responsible for clarifying the standards of acceptable
37 | behavior and are expected to take appropriate and fair corrective action in
38 | response to any instances of unacceptable behavior.
39 |
40 | Project maintainers have the right and responsibility to remove, edit, or
41 | reject comments, commits, code, wiki edits, issues, and other contributions
42 | that are not aligned to this Code of Conduct, or to ban temporarily or
43 | permanently any contributor for other behaviors that they deem inappropriate,
44 | threatening, offensive, or harmful.
45 |
46 | ## Scope
47 |
48 | This Code of Conduct applies both within project spaces and in public spaces
49 | when an individual is representing the project or its community. Examples of
50 | representing a project or community include using an official project e-mail
51 | address, posting via an official social media account, or acting as an appointed
52 | representative at an online or offline event. Representation of a project may be
53 | further defined and clarified by project maintainers.
54 |
55 | ## Enforcement
56 |
57 | Instances of abusive, harassing, or otherwise unacceptable behavior may be
58 | reported by contacting the project team at kent+coc@doddsfamily.us. All
59 | complaints will be reviewed and investigated and will result in a response that
60 | is deemed necessary and appropriate to the circumstances. The project team is
61 | obligated to maintain confidentiality with regard to the reporter of an incident.
62 | Further details of specific enforcement policies may be posted separately.
63 |
64 | Project maintainers who do not follow or enforce the Code of Conduct in good
65 | faith may face temporary or permanent repercussions as determined by other
66 | members of the project's leadership.
67 |
68 | ## Attribution
69 |
70 | This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4,
71 | available at [http://contributor-covenant.org/version/1/4][version]
72 |
73 | [homepage]: http://contributor-covenant.org
74 | [version]: http://contributor-covenant.org/version/1/4/
75 |
--------------------------------------------------------------------------------
/other/MAINTAINING.md:
--------------------------------------------------------------------------------
1 | # Maintaining
2 |
3 | This is documentation for maintainers of this project.
4 |
5 | ## Code of Conduct
6 |
7 | Please review, understand, and be an example of it. Violations of the code of conduct are
8 | taken seriously, even (especially) for maintainers.
9 |
10 | ## Issues
11 |
12 | We want to support and build the community. We do that best by helping people learn to solve
13 | their own problems. We have an issue template and hopefully most folks follow it. If it's
14 | not clear what the issue is, invite them to create a minimal reproduction of what they're trying
15 | to accomplish or the bug they think they've found.
16 |
17 | Once it's determined that a code change is necessary, point people to
18 | [makeapullrequest.com](http://makeapullrequest.com) and invite them to make a pull request.
19 | If they're the one who needs the feature, they're the one who can build it. If they need
20 | some hand holding and you have time to lend a hand, please do so. It's an investment into
21 | another human being, and an investment into a potential maintainer.
22 |
23 | Remember that this is open source, so the code is not yours, it's ours. If someone needs a change
24 | in the codebase, you don't have to make it happen yourself. Commit as much time to the project
25 | as you want/need to. Nobody can ask any more of you than that.
26 |
27 | ## Pull Requests
28 |
29 | As a maintainer, you're fine to make your branches on the main repo or on your own fork. Either
30 | way is fine.
31 |
32 | When we receive a pull request, a travis build is kicked off automatically (see the `.travis.yml`
33 | for what runs in the travis build). We avoid merging anything that breaks the travis build.
34 |
35 | Please review PRs and focus on the code rather than the individual. You never know when this is
36 | someone's first ever PR and we want their experience to be as positive as possible, so be
37 | uplifting and constructive.
38 |
39 | When you merge the pull request, 99% of the time you should use the
40 | [Squash and merge](https://help.github.com/articles/merging-a-pull-request/) feature. This keeps
41 | our git history clean, but more importantly, this allows us to make any necessary changes to the
42 | commit message so we release what we want to release. See the next section on Releases for more
43 | about that.
44 |
45 | ## Release
46 |
47 | Our releases are automatic. They happen whenever code lands into `master`. A travis build gets
48 | kicked off and if it's successful, a tool called
49 | [`semantic-release`](https://github.com/semantic-release/semantic-release) is used to
50 | automatically publish a new release to npm as well as a changelog to GitHub. It is only able to
51 | determine the version and whether a release is necessary by the git commit messages. With this
52 | in mind, **please brush up on [the commit message convention][commit] which drives our releases.**
53 |
54 | > One important note about this: Please make sure that commit messages do NOT contain the words
55 | > "BREAKING CHANGE" in them unless we want to push a major version. I've been burned by this
56 | > more than once where someone will include "BREAKING CHANGE: None" and it will end up releasing
57 | > a new major version. Not a huge deal honestly, but kind of annoying...
58 |
59 | ## Thanks!
60 |
61 | Thank you so much for helping to maintain this project!
62 |
63 | [commit]: https://github.com/conventional-changelog-archived-repos/conventional-changelog-angular/blob/ed32559941719a130bb0327f886d6a32a8cbc2ba/convention.md
64 |
--------------------------------------------------------------------------------
/other/USERS.md:
--------------------------------------------------------------------------------
1 | # Users
2 |
3 | If you or your company uses this project, add your name to this list! Eventually
4 | we may have a website to showcase these (wanna build it!?)
5 |
6 | > No users have been added yet!
7 |
8 |
13 |
--------------------------------------------------------------------------------
/other/manual-releases.md:
--------------------------------------------------------------------------------
1 | # manual-releases
2 |
3 | This project has an automated release set up. So things are only released when there are
4 | useful changes in the code that justify a release. But sometimes things get messed up one way or another
5 | and we need to trigger the release ourselves. When this happens, simply bump the number below and commit
6 | that with the following commit message based on your needs:
7 |
8 | **Major**
9 |
10 | ```
11 | fix(release): manually release a major version
12 |
13 | There was an issue with a major release, so this manual-releases.md
14 | change is to release a new major version.
15 |
16 | Reference: #