CDN/bifrost-registry
3
0
Fork 0
Code Issues Pull Requests Packages Projects Releases 1 Wiki Activity

refactor(scripts): update gen_commit.py and remove commit convention file

Browse Source
This commit is contained in:
Hoàng
2025-05-14 08:56:03 +07:00
parent 06a27404f9
commit 93f42839f9
3 changed files with 128 additions and 51 deletions
Download Patch File Download Diff File Expand all files Collapse all files
scripts/interpreter/gen_commit.py
+1 -1
View File
@@ -40,7 +40,7 @@ def gen_commit(project_path):
agent = OpenInterpreter()
agent.auto_run = True
with open(
os.path.join(os.path.dirname(__file__), "resources/commit_convention.txt"),
os.path.join(os.path.dirname(__file__), "resources/commit_convention.md"),
"r",
) as f:
file_content = f.read()
scripts/interpreter/resources/commit_convention.md
+127
View File
@@ -0,0 +1,127 @@
# Conventional Commit Messages
See how [a minor change](#examples) to your commit message style can make a difference.
> [!TIP]
> Take a look at **[git-conventional-commits](https://github.com/qoomon/git-conventional-commits)** , a CLI util to ensure these conventions, determine version and generate changelogs
## Commit Message Formats
### Default
<pre>
<b><a href="#types">&lt;type&gt;</a></b></font>(<b><a href="#scopes">&lt;optional scope&gt;</a></b>): <b><a href="#description">&lt;description&gt;</a></b>
<sub>empty separator line</sub>
<b><a href="#body">&lt;optional body&gt;</a></b>
<sub>empty separator line</sub>
<b><a href="#footer">&lt;optional footer&gt;</a></b>
</pre>
### Merge Commit
<pre>
Merge branch '<b>&lt;branch name&gt;</b>'
</pre>
<sup>Follows default git merge message</sup>
### Revert Commit
<pre>
Revert "<b>&lt;reverted commit subject line&gt;</b>"
</pre>
<sup>Follows default git revert message</sup>
### Inital Commit
```
chore: init
```
### Types
- API or UI relevant changes
- `feat` Commits, that add or remove a new feature to the API or UI
- `fix` Commits, that fix an API or UI bug of a preceded `feat` commit
- `refactor` Commits, that rewrite/restructure your code, however do not change any API or UI behaviour
- `perf` Commits are special `refactor` commits, that improve performance
- `style` Commits, that do not affect the meaning (white-space, formatting, missing semi-colons, etc)
- `test` Commits, that add missing tests or correcting existing tests
- `docs` Commits, that affect documentation only
- `build` Commits, that affect build components like build tools, dependencies, project version, ci pipelines, ...
- `ops` Commits, that affect operational components like infrastructure, deployment, backup, recovery, ...
- `chore` Miscellaneous commits e.g. modifying `.gitignore`
### Scopes
The `scope` provides additional contextual information.
* Is an **optional** part of the format
* Allowed Scopes depend on the specific project
* Don't use issue identifiers as scopes
### Breaking Changes Indicator
Breaking changes should be indicated by an `!` before the `:` in the subject line e.g. `feat(api)!: remove status endpoint`
- Is an **optional** part of the format
- Breaking changes **must** be described in the [commit footer section](#footer)
### Description
The `description` contains a concise description of the change.
- It is a **mandatory** part of the format
- Use the imperative, present tense: "change" not "changed" nor "changes"
- Think of `This commit will...` or `This commit should...`
- Don't capitalize the first letter
- No dot (`.`) at the end
### Body
The `body` should include the motivation for the change and contrast this with previous behavior.
- Is an **optional** part of the format
- Use the imperative, present tense: "change" not "changed" nor "changes"
- This is the place to mention issue identifiers and their relations
### Footer
The `footer` should contain any information about **Breaking Changes** and is also the place to **reference Issues** that this commit refers to.
- Is an **optional** part of the format
- **optionally** reference an issue by its id.
- **Breaking Changes** should start with the word `BREAKING CHANGE:` followed by space or two newlines. The rest of the commit message is then used for this.
### Versioning
- **If** your next release contains commit with...
- **breaking changes** incremented the **major version**
- **API relevant changes** (`feat` or `fix`) incremented the **minor version**
- **Else** increment the **patch version**
### Examples
- ```
feat: add email notifications on new direct messages
```
- ```
feat(shopping cart): add the amazing button
```
- ```
feat!: remove ticket list endpoint
refers to JIRA-1337
BREAKING CHANGE: ticket endpoints no longer supports list all entities.
```
- ```
fix(shopping-cart): prevent order an empty shopping cart
```
- ```
fix(api): fix wrong calculation of request body checksum
```
- ```
fix: add missing parameter to service call
The error occurred due to <reasons>.
```
- ```
perf: decrease memory footprint for determine uniqe visitors by using HyperLogLog
```
- ```
build: update dependencies
```
- ```
build(release): bump version to 1.0.0
```
- ```
refactor: implement fibonacci number calculation as recursion
```
- ```
style: remove empty line
```
scripts/interpreter/resources/commit_convention.txt
-50
View File
@@ -1,50 +0,0 @@
Git Commit Guidelines
Git Commit
This documented was extracted from Contributing to AngularJS. Every contributor to the project should be aware of the following rules.
We have very precise rules over how our git commit messages can be formatted. This leads to more readable messages that are easy to follow when looking through the project history. But also, we use the git commit messages to generate the theme framework change log.
The commit message formatting can be added using a typical git workflow or through the use of a CLI wizard (Commitizen). To use the wizard, run npm run commit in your terminal after staging your changes in git.
Commit Message Format
Each commit message consists of a header, a body and a footer. The header has a special format that includes a type, a scope and a subject:
<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>
The header is mandatory and the scope of the header is optional.
Any line of the commit message cannot be longer 100 characters! This allows the message to be easier to read on GitHub as well as in various git tools.
Revert
If the commit reverts a previous commit, it should begin with revert:, followed by the header of the reverted commit. In the body it should say: This reverts commit <hash>., where the hash is the SHA of the commit being reverted.
Type
Must be one of the following:
feat: A new feature
fix: A bug fix
docs: Documentation only changes
style: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
refactor: A code change that neither fixes a bug nor adds a feature
perf: A code change that improves performance
test: Adding missing tests
chore: Changes to the build process or auxiliary tools and libraries such as documentation generation
Scope
The scope could be anything specifying place of the commit change. For example $location, $browser, $compile, $rootScope, ngHref, ngClick, ngView, etc…
Subject
The subject contains succinct description of the change:
use the imperative, present tense: “change” not “changed” nor “changes”
don’t capitalize first letter
no dot (.) at the end
Body
Just as in the subject, use the imperative, present tense: “change” not “changed” nor “changes”. The body should include the motivation for the change and contrast this with previous behavior.
Footer
The footer should contain any information about Breaking Changes and is also the place to reference GitHub issues that this commit Closes.
Breaking Changes should start with the word BREAKING CHANGE: with a space or two newlines. The rest of the commit message is then used for this.