p2kmgcl / seniore Goto Github PK

Angular conventional commits are being used through the whole project (see contributing guidelines).

One of the benefits of this (apart from having a more readable commit history) was having a automated release process that generates changelogs and GitHub/NPM releases when necessary: working ci workflow.

However, for some reason, plugins being used generated a full changelog even when just a few commits where added, releasing breaking changes everytime. Because of this, this automated process have been disabled until releases become stable.

This error is found sometimes when modifying JIRA tickets

(node:47130) UnhandledPromiseRejectionWarning: RequestError: Error: Parse Error: Invalid character in chunk size
    at new RequestError (/home/p2kmgcl/Projects/seniore/node_modules/request-promise-core/lib/errors.js:14:15)
    at Request.plumbing.callback (/home/p2kmgcl/Projects/seniore/node_modules/request-promise-core/lib/plumbing.js:87:29)
    at Request.RP$callback [as _callback] (/home/p2kmgcl/Projects/seniore/node_modules/request-promise-core/lib/plumbing.js:46:31)
    at self.callback (/home/p2kmgcl/Projects/seniore/node_modules/request/request.js:185:22)
    at Request.emit (events.js:314:20)
    at Request.onRequestError (/home/p2kmgcl/Projects/seniore/node_modules/request/request.js:877:8)
    at ClientRequest.emit (events.js:314:20)
    at TLSSocket.socketOnData (_http_client.js:516:9)
    at TLSSocket.emit (events.js:314:20)
    at addChunk (_stream_readable.js:308:12)
    at readableAddChunk (_stream_readable.js:283:9)
    at TLSSocket.Readable.push (_stream_readable.js:222:10)
    at TLSWrap.onStreamRead (internal/stream_base_commons.js:188:23)
(Use `node --trace-warnings ...` to show where the warning was created)
(node:47130) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag `--unhandled-rejections=strict` (see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 1)
(node:47130) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.

If using conventional commits, we are adding the associated JIRA ticket at the end of the commit. We should support two new syntax:

• fix: Make this work (LPS-1234)
• fix(LPS-1234): Make this work

Currently notifications only allow two things: listing all notifications and clearing the notification list. This experience is quite poor as notifications are an important part of the workflow.

This new proposal includes presenting an interactive list of existing notifications dan can be opened, mark as read, etc. More about this when I have time 😅

Contributions are welcome!

octokit.repos.listStatusesForRef() has been renamed to octokit.repos.listCommitStatusesForRef()

should not appear.

When seniore adds a link to the forwarded pull request, a github notification is generated. This notification should automatically be marked as done.

Currently some of seniore commands rely on an existing master branch to, for example, clear a branch after sending PR.

We should rely on new git features to detect a local repository default branch.

Currently the only way to configure seniore is managing the existing JSON file that contains all keys. This file is well documented, but forcing users to change it manually is not the best we can do.

The idea is to update this file format to a more simple key-value file used by tools like git (yep, I am that original):

github.token = hdyd63hfu36jdu
jira.host = issues.liferay.com
...

After that restructuring, we can add a new config command that allows modifying the configuration without touching the actual file. As a result, we can avoid such a bad experience like

Configuration file not found. Run seniore init

Although the --help option helps (ha!) discovering existing commands, is not a good starting point for new users.

I would like to avoid documentation duplication as far as I can, and that's why I need to investigate how to provide both a good API and better documentation.

One idea that comes to my mind is investigating man files and existing CLIs and see how they work ©️

https://app.leanboard.io/board/19a523e4-3d42-4211-91b7-96a9297b9a2a

⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️