├── .github ├── FUNDING.yml ├── ISSUE_TEMPLATE │ ├── bug_report.md │ └── feature_request.md ├── workflows │ └── codeql-analysis.yml └── workkflows │ └── codeql-analysis.yml ├── .travis.yml ├── CODE_OF_CONDUCT.md ├── CONTRIBUTING.md ├── LICENSE ├── README.md ├── README_zh.md ├── SECURITY.md ├── codelingo.yaml ├── glc.go ├── glc.png ├── glc_test.go ├── go.mod └── logo.png /.github/FUNDING.yml: -------------------------------------------------------------------------------- 1 | patreon: xuri 2 | ko_fi: xurime 3 | liberapay: xuri 4 | issuehunt: xuri 5 | -------------------------------------------------------------------------------- /.github/ISSUE_TEMPLATE/bug_report.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Bug report 3 | about: Create a report to help us improve 4 | 5 | --- 6 | 7 | 16 | 17 | **Description** 18 | 19 | 22 | 23 | **Steps to reproduce the issue:** 24 | 1. 25 | 2. 26 | 3. 27 | 28 | **Describe the results you received:** 29 | 30 | 31 | **Describe the results you expected:** 32 | 33 | 34 | **Output of `go version`:** 35 | 36 | ``` 37 | (paste your output here) 38 | ``` 39 | 40 | **Aurora version or commit ID:** 41 | 42 | ``` 43 | (paste here) 44 | ``` 45 | 46 | **Environment details (OS, physical, etc.):** 47 | -------------------------------------------------------------------------------- /.github/ISSUE_TEMPLATE/feature_request.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Feature request 3 | about: Suggest an idea for this project 4 | 5 | --- 6 | 7 | **Is your feature request related to a problem? Please describe.** 8 | A clear and concise description of what the problem is. Ex. I'm always frustrated when [...] 9 | 10 | **Describe the solution you'd like** 11 | A clear and concise description of what you want to happen. 12 | 13 | **Describe alternatives you've considered** 14 | A clear and concise description of any alternative solutions or features you've considered. 15 | 16 | **Additional context** 17 | Add any other context or screenshots about the feature request here. 18 | -------------------------------------------------------------------------------- /.github/workflows/codeql-analysis.yml: -------------------------------------------------------------------------------- 1 | # For most projects, this workflow file will not need changing; you simply need 2 | # to commit it to your repository. 3 | # 4 | # You may wish to alter this file to override the set of languages analyzed, 5 | # or to provide custom queries or build logic. 6 | # 7 | # ******** NOTE ******** 8 | # We have attempted to detect the languages in your repository. Please check 9 | # the `language` matrix defined below to confirm you have the correct set of 10 | # supported CodeQL languages. 11 | # ******** NOTE ******** 12 | 13 | name: "CodeQL" 14 | 15 | on: 16 | push: 17 | branches: [ master ] 18 | pull_request: 19 | # The branches below must be a subset of the branches above 20 | branches: [ master ] 21 | schedule: 22 | - cron: '45 11 * * 3' 23 | 24 | jobs: 25 | analyze: 26 | name: Analyze 27 | runs-on: ubuntu-latest 28 | 29 | strategy: 30 | fail-fast: false 31 | matrix: 32 | language: [ 'go' ] 33 | # CodeQL supports [ 'cpp', 'csharp', 'go', 'java', 'javascript', 'python' ] 34 | # Learn more... 35 | # https://docs.github.com/en/github/finding-security-vulnerabilities-and-errors-in-your-code/configuring-code-scanning#overriding-automatic-language-detection 36 | 37 | steps: 38 | - name: Checkout repository 39 | uses: actions/checkout@v2 40 | 41 | # Initializes the CodeQL tools for scanning. 42 | - name: Initialize CodeQL 43 | uses: github/codeql-action/init@v1 44 | with: 45 | languages: ${{ matrix.language }} 46 | # If you wish to specify custom queries, you can do so here or in a config file. 47 | # By default, queries listed here will override any specified in a config file. 48 | # Prefix the list here with "+" to use these queries and those in the config file. 49 | # queries: ./path/to/local/query, your-org/your-repo/queries@main 50 | 51 | # Autobuild attempts to build any compiled languages (C/C++, C#, or Java). 52 | # If this step fails, then you should remove it and run the build manually (see below) 53 | - name: Autobuild 54 | uses: github/codeql-action/autobuild@v1 55 | 56 | # ℹ️ Command-line programs to run using the OS shell. 57 | # 📚 https://git.io/JvXDl 58 | 59 | # ✏️ If the Autobuild fails above, remove it and uncomment the following three lines 60 | # and modify them (or add more) to build your code if your project 61 | # uses a compiled language 62 | 63 | #- run: | 64 | # make bootstrap 65 | # make release 66 | 67 | - name: Perform CodeQL Analysis 68 | uses: github/codeql-action/analyze@v1 69 | -------------------------------------------------------------------------------- /.github/workkflows/codeql-analysis.yml: -------------------------------------------------------------------------------- 1 | # For most projects, this workflow file will not need changing; you simply need 2 | # to commit it to your repository. 3 | # 4 | # You may wish to alter this file to override the set of languages analyzed, 5 | # or to provide custom queries or build logic. 6 | name: "CodeQL" 7 | 8 | on: 9 | push: 10 | branches: [master] 11 | pull_request: 12 | # The branches below must be a subset of the branches above 13 | branches: [master] 14 | schedule: 15 | - cron: '0 21 * * 3' 16 | 17 | jobs: 18 | analyze: 19 | name: Analyze 20 | runs-on: ubuntu-latest 21 | 22 | strategy: 23 | fail-fast: false 24 | matrix: 25 | # Override automatic language detection by changing the below list 26 | # Supported options are ['csharp', 'cpp', 'go', 'java', 'javascript', 'python'] 27 | language: ['go'] 28 | # Learn more... 29 | # https://docs.github.com/en/github/finding-security-vulnerabilities-and-errors-in-your-code/configuring-code-scanning#overriding-automatic-language-detection 30 | 31 | steps: 32 | - name: Checkout repository 33 | uses: actions/checkout@v2 34 | with: 35 | # We must fetch at least the immediate parents so that if this is 36 | # a pull request then we can checkout the head. 37 | fetch-depth: 2 38 | 39 | # If this run was triggered by a pull request event, then checkout 40 | # the head of the pull request instead of the merge commit. 41 | - run: git checkout HEAD^2 42 | if: ${{ github.event_name == 'pull_request' }} 43 | 44 | # Initializes the CodeQL tools for scanning. 45 | - name: Initialize CodeQL 46 | uses: github/codeql-action/init@v1 47 | with: 48 | languages: ${{ matrix.language }} 49 | # If you wish to specify custom queries, you can do so here or in a config file. 50 | # By default, queries listed here will override any specified in a config file. 51 | # Prefix the list here with "+" to use these queries and those in the config file. 52 | # queries: ./path/to/local/query, your-org/your-repo/queries@main 53 | 54 | # Autobuild attempts to build any compiled languages (C/C++, C#, or Java). 55 | # If this step fails, then you should remove it and run the build manually (see below) 56 | - name: Autobuild 57 | uses: github/codeql-action/autobuild@v1 58 | 59 | # ℹ️ Command-line programs to run using the OS shell. 60 | # 📚 https://git.io/JvXDl 61 | 62 | # ✏️ If the Autobuild fails above, remove it and uncomment the following three lines 63 | # and modify them (or add more) to build your code if your project 64 | # uses a compiled language 65 | 66 | #- run: | 67 | # make bootstrap 68 | # make release 69 | 70 | - name: Perform CodeQL Analysis 71 | uses: github/codeql-action/analyze@v1 72 | -------------------------------------------------------------------------------- /.travis.yml: -------------------------------------------------------------------------------- 1 | language: go 2 | 3 | sudo: required 4 | 5 | before_install: 6 | - go get github.com/golang/glog 7 | 8 | go: 9 | - 1.8.x 10 | - 1.9.x 11 | - 1.10.x 12 | - 1.11.x 13 | - 1.12.x 14 | 15 | os: 16 | - linux 17 | - osx 18 | 19 | env: 20 | matrix: 21 | - GOARCH=amd64 22 | - GOARCH=386 23 | 24 | script: 25 | - go vet ./... 26 | - go test -v -coverprofile=coverage.txt -covermode=atomic 27 | 28 | after_success: 29 | - bash <(curl -s https://codecov.io/bash) -------------------------------------------------------------------------------- /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 contributors and maintainers pledge to making participation in our project and our community a harassment-free experience for everyone, regardless of age, body size, disability, ethnicity, gender identity and expression, level of experience, nationality, personal appearance, race, religion, or sexual identity and orientation. 6 | 7 | ## Our Standards 8 | 9 | Examples of behavior that contributes to creating a positive environment include: 10 | 11 | * Using welcoming and inclusive language 12 | * Being respectful of differing viewpoints and experiences 13 | * Gracefully accepting constructive criticism 14 | * Focusing on what is best for the community 15 | * Showing empathy towards other community members 16 | 17 | Examples of unacceptable behavior by participants include: 18 | 19 | * The use of sexualized language or imagery and unwelcome sexual attention or advances 20 | * Trolling, insulting/derogatory comments, and personal or political attacks 21 | * Public or private harassment 22 | * Publishing others' private information, such as a physical or electronic address, without explicit permission 23 | * Other conduct which could reasonably be considered inappropriate in a professional setting 24 | 25 | ## Our Responsibilities 26 | 27 | Project maintainers are responsible for clarifying the standards of acceptable behavior and are expected to take appropriate and fair corrective action in response to any instances of unacceptable behavior. 28 | 29 | Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, or to ban temporarily or permanently any contributor for other behaviors that they deem inappropriate, threatening, offensive, or harmful. 30 | 31 | ## Scope 32 | 33 | This Code of Conduct applies both within project spaces and in public spaces when an individual is representing the project or its community. Examples of representing a project or community include using an official project e-mail address, posting via an official social media account, or acting as an appointed representative at an online or offline event. Representation of a project may be further defined and clarified by project maintainers. 34 | 35 | ## Enforcement 36 | 37 | Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting the project team at [xuri.me](https://xuri.me). The project team will review and investigate all complaints, and will respond in a way that it deems appropriate to the circumstances. The project team is obligated to maintain confidentiality with regard to the reporter of an incident. Further details of specific enforcement policies may be posted separately. 38 | 39 | Project maintainers who do not follow or enforce the Code of Conduct in good faith may face temporary or permanent repercussions as determined by other members of the project's leadership. 40 | 41 | ## Attribution 42 | 43 | This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4, available at [http://contributor-covenant.org/version/1/4][version] 44 | 45 | [homepage]: http://contributor-covenant.org 46 | [version]: http://contributor-covenant.org/version/1/4/ 47 | -------------------------------------------------------------------------------- /CONTRIBUTING.md: -------------------------------------------------------------------------------- 1 | # Contributing to GLC 2 | 3 | Want to hack on GLC? Awesome! This page contains information about reporting issues as well as some tips and 4 | guidelines useful to experienced open source contributors. Finally, make sure 5 | you read our [community guidelines](#community-guidelines) before you 6 | start participating. 7 | 8 | ## Topics 9 | 10 | * [Reporting Security Issues](#reporting-security-issues) 11 | * [Design and Cleanup Proposals](#design-and-cleanup-proposals) 12 | * [Reporting Issues](#reporting-other-issues) 13 | * [Quick Contribution Tips and Guidelines](#quick-contribution-tips-and-guidelines) 14 | * [Community Guidelines](#community-guidelines) 15 | 16 | ## Reporting security issues 17 | 18 | The GLC maintainers take security seriously. If you discover a security 19 | issue, please bring it to their attention right away! 20 | 21 | Please **DO NOT** file a public issue, instead send your report privately to 22 | [xuri.me](https://xuri.me). 23 | 24 | Security reports are greatly appreciated and we will publicly thank you for it. 25 | We currently do not offer a paid security bounty program, but are not 26 | ruling it out in the future. 27 | 28 | ## Reporting other issues 29 | 30 | A great way to contribute to the project is to send a detailed report when you 31 | encounter an issue. We always appreciate a well-written, thorough bug report, 32 | and will thank you for it! 33 | 34 | Check that [our issue database](https://github.com/xuri/GLC/issues) 35 | doesn't already include that problem or suggestion before submitting an issue. 36 | If you find a match, you can use the "subscribe" button to get notified on 37 | updates. Do *not* leave random "+1" or "I have this too" comments, as they 38 | only clutter the discussion, and don't help resolving it. However, if you 39 | have ways to reproduce the issue or have additional information that may help 40 | resolving the issue, please leave a comment. 41 | 42 | When reporting issues, always include the output of `go env`. 43 | 44 | Also include the steps required to reproduce the problem if possible and 45 | applicable. This information will help us review and fix your issue faster. 46 | When sending lengthy log-files, consider posting them as a gist [https://gist.github.com](https://gist.github.com). 47 | Don't forget to remove sensitive data from your logfiles before posting (you can 48 | replace those parts with "REDACTED"). 49 | 50 | ## Quick contribution tips and guidelines 51 | 52 | This section gives the experienced contributor some tips and guidelines. 53 | 54 | ### Pull requests are always welcome 55 | 56 | Not sure if that typo is worth a pull request? Found a bug and know how to fix 57 | it? Do it! We will appreciate it. Any significant improvement should be 58 | documented as [a GitHub issue](https://github.com/xuri/GLC/issues) before 59 | anybody starts working on it. 60 | 61 | We are always thrilled to receive pull requests. We do our best to process them 62 | quickly. If your pull request is not accepted on the first try, 63 | don't get discouraged! 64 | 65 | ### Design and cleanup proposals 66 | 67 | You can propose new designs for existing GLC features. You can also design 68 | entirely new features. We really appreciate contributors who want to refactor or 69 | otherwise cleanup our project. 70 | 71 | We try hard to keep GLC lean and focused. GLC can't do everything for 72 | everybody. This means that we might decide against incorporating a new feature. 73 | However, there might be a way to implement that feature *on top of* GLC. 74 | 75 | ### Conventions 76 | 77 | Fork the repository and make changes on your fork in a feature branch: 78 | 79 | * If it's a bug fix branch, name it XXXX-something where XXXX is the number of 80 | the issue. 81 | * If it's a feature branch, create an enhancement issue to announce 82 | your intentions, and name it XXXX-something where XXXX is the number of the 83 | issue. 84 | 85 | Submit unit tests for your changes. Go has a great test framework built in; use 86 | it! Take a look at existing tests for inspiration. Run the full test on your branch before 87 | submitting a pull request. 88 | 89 | Update the documentation when creating or modifying features. Test your 90 | documentation changes for clarity, concision, and correctness, as well as a 91 | clean documentation build. 92 | 93 | Write clean code. Universally formatted code promotes ease of writing, reading, 94 | and maintenance. Always run `gofmt -s -w file.go` on each changed file before 95 | committing your changes. Most editors have plug-ins that do this automatically. 96 | 97 | Pull request descriptions should be as clear as possible and include a reference 98 | to all the issues that they address. 99 | 100 | ### Successful Changes 101 | 102 | Before contributing large or high impact changes, make the effort to coordinate 103 | with the maintainers of the project before submitting a pull request. This 104 | prevents you from doing extra work that may or may not be merged. 105 | 106 | Large PRs that are just submitted without any prior communication are unlikely 107 | to be successful. 108 | 109 | While pull requests are the methodology for submitting changes to code, changes 110 | are much more likely to be accepted if they are accompanied by additional 111 | engineering work. While we don't define this explicitly, most of these goals 112 | are accomplished through communication of the design goals and subsequent 113 | solutions. Often times, it helps to first state the problem before presenting 114 | solutions. 115 | 116 | Typically, the best methods of accomplishing this are to submit an issue, 117 | stating the problem. This issue can include a problem statement and a 118 | checklist with requirements. If solutions are proposed, alternatives should be 119 | listed and eliminated. Even if the criteria for elimination of a solution is 120 | frivolous, say so. 121 | 122 | Larger changes typically work best with design documents. These are focused on 123 | providing context to the design at the time the feature was conceived and can 124 | inform future documentation contributions. 125 | 126 | ### Commit Messages 127 | 128 | Commit messages must start with a capitalized and short summary 129 | written in the imperative, followed by an optional, more detailed explanatory 130 | text which is separated from the summary by an empty line. 131 | 132 | Commit messages should follow best practices, including explaining the context 133 | of the problem and how it was solved, including in caveats or follow up changes 134 | required. They should tell the story of the change and provide readers 135 | understanding of what led to it. 136 | 137 | In practice, the best approach to maintaining a nice commit message is to 138 | leverage a `git add -p` and `git commit --amend` to formulate a solid 139 | changeset. This allows one to piece together a change, as information becomes 140 | available. 141 | 142 | If you squash a series of commits, don't just submit that. Re-write the commit 143 | message, as if the series of commits was a single stroke of brilliance. 144 | 145 | That said, there is no requirement to have a single commit for a PR, as long as 146 | each commit tells the story. For example, if there is a feature that requires a 147 | package, it might make sense to have the package in a separate commit then have 148 | a subsequent commit that uses it. 149 | 150 | Remember, you're telling part of the story with the commit message. Don't make 151 | your chapter weird. 152 | 153 | ### Review 154 | 155 | Code review comments may be added to your pull request. Discuss, then make the 156 | suggested modifications and push additional commits to your feature branch. Post 157 | a comment after pushing. New commits show up in the pull request automatically, 158 | but the reviewers are notified only when you comment. 159 | 160 | Pull requests must be cleanly rebased on top of master without multiple branches 161 | mixed into the PR. 162 | 163 | **Git tip**: If your PR no longer merges cleanly, use `rebase master` in your 164 | feature branch to update your pull request rather than `merge master`. 165 | 166 | Before you make a pull request, squash your commits into logical units of work 167 | using `git rebase -i` and `git push -f`. A logical unit of work is a consistent 168 | set of patches that should be reviewed together: for example, upgrading the 169 | version of a vendored dependency and taking advantage of its now available new 170 | feature constitute two separate units of work. Implementing a new function and 171 | calling it in another file constitute a single logical unit of work. The very 172 | high majority of submissions should have a single commit, so if in doubt: squash 173 | down to one. 174 | 175 | After every commit, make sure the test passes. Include documentation 176 | changes in the same pull request so that a revert would remove all traces of 177 | the feature or fix. 178 | 179 | Include an issue reference like `Closes #XXXX` or `Fixes #XXXX` in commits that 180 | close an issue. Including references automatically closes the issue on a merge. 181 | 182 | Please see the [Coding Style](#coding-style) for further guidelines. 183 | 184 | ### Merge approval 185 | 186 | The GLC maintainers use LGTM (Looks Good To Me) in comments on the code review to 187 | indicate acceptance. 188 | 189 | ### Sign your work 190 | 191 | The sign-off is a simple line at the end of the explanation for the patch. Your 192 | signature certifies that you wrote the patch or otherwise have the right to pass 193 | it on as an open-source patch. The rules are pretty simple: if you can certify 194 | the below (from [developercertificate.org](http://developercertificate.org/)): 195 | 196 | ```text 197 | Developer Certificate of Origin 198 | Version 1.1 199 | 200 | Copyright (C) 2004, 2006 The Linux Foundation and its contributors. 201 | 1 Letterman Drive 202 | Suite D4700 203 | San Francisco, CA, 94129 204 | 205 | Everyone is permitted to copy and distribute verbatim copies of this 206 | license document, but changing it is not allowed. 207 | 208 | Developer's Certificate of Origin 1.1 209 | 210 | By making a contribution to this project, I certify that: 211 | 212 | (a) The contribution was created in whole or in part by me and I 213 | have the right to submit it under the open source license 214 | indicated in the file; or 215 | 216 | (b) The contribution is based upon previous work that, to the best 217 | of my knowledge, is covered under an appropriate open source 218 | license and I have the right under that license to submit that 219 | work with modifications, whether created in whole or in part 220 | by me, under the same open source license (unless I am 221 | permitted to submit under a different license), as indicated 222 | in the file; or 223 | 224 | (c) The contribution was provided directly to me by some other 225 | person who certified (a), (b) or (c) and I have not modified 226 | it. 227 | 228 | (d) I understand and agree that this project and the contribution 229 | are public and that a record of the contribution (including all 230 | personal information I submit with it, including my sign-off) is 231 | maintained indefinitely and may be redistributed consistent with 232 | this project or the open source license(s) involved. 233 | ``` 234 | 235 | Then you just add a line to every git commit message: 236 | 237 | Signed-off-by: Ri Xu https://xuri.me 238 | 239 | Use your real name (sorry, no pseudonyms or anonymous contributions.) 240 | 241 | If you set your `user.name` and `user.email` git configs, you can sign your 242 | commit automatically with `git commit -s`. 243 | 244 | ### How can I become a maintainer 245 | 246 | First, all maintainers have 3 things 247 | 248 | * They share responsibility in the project's success. 249 | * They have made a long-term, recurring time investment to improve the project. 250 | * They spend that time doing whatever needs to be done, not necessarily what is the most interesting or fun. 251 | 252 | Maintainers are often under-appreciated, because their work is harder to appreciate. 253 | It's easy to appreciate a really cool and technically advanced feature. It's harder 254 | to appreciate the absence of bugs, the slow but steady improvement in stability, 255 | or the reliability of a release process. But those things distinguish a good 256 | project from a great one. 257 | 258 | Don't forget: being a maintainer is a time investment. Make sure you 259 | will have time to make yourself available. You don't have to be a 260 | maintainer to make a difference on the project! 261 | 262 | If you want to become a meintainer, contact [xuri.me](https://xuri.me) and given a introduction of you. 263 | 264 | ## Community guidelines 265 | 266 | We want to keep the community awesome, growing and collaborative. We need 267 | your help to keep it that way. To help with this we've come up with some general 268 | guidelines for the community as a whole: 269 | 270 | * Be nice: Be courteous, respectful and polite to fellow community members: 271 | no regional, racial, gender, or other abuse will be tolerated. We like 272 | nice people way better than mean ones! 273 | 274 | * Encourage diversity and participation: Make everyone in our community feel 275 | welcome, regardless of their background and the extent of their 276 | contributions, and do everything possible to encourage participation in 277 | our community. 278 | 279 | * Keep it legal: Basically, don't get us in trouble. Share only content that 280 | you own, do not share private or sensitive information, and don't break 281 | the law. 282 | 283 | * Stay on topic: Make sure that you are posting to the correct channel and 284 | avoid off-topic discussions. Remember when you update an issue or respond 285 | to an email you are potentially sending to a large number of people. Please 286 | consider this before you update. Also remember that nobody likes spam. 287 | 288 | * Don't send email to the maintainers: There's no need to send email to the 289 | maintainers to ask them to investigate an issue or to take a look at a 290 | pull request. Instead of sending an email, GitHub mentions should be 291 | used to ping maintainers to review a pull request, a proposal or an 292 | issue. 293 | 294 | ### Guideline violations — 3 strikes method 295 | 296 | The point of this section is not to find opportunities to punish people, but we 297 | do need a fair way to deal with people who are making our community suck. 298 | 299 | 1. First occurrence: We'll give you a friendly, but public reminder that the 300 | behavior is inappropriate according to our guidelines. 301 | 302 | 2. Second occurrence: We will send you a private message with a warning that 303 | any additional violations will result in removal from the community. 304 | 305 | 3. Third occurrence: Depending on the violation, we may need to delete or ban 306 | your account. 307 | 308 | **Notes:** 309 | 310 | * Obvious spammers are banned on first occurrence. If we don't do this, we'll 311 | have spam all over the place. 312 | 313 | * Violations are forgiven after 6 months of good behavior, and we won't hold a 314 | grudge. 315 | 316 | * People who commit minor infractions will get some education, rather than 317 | hammering them in the 3 strikes process. 318 | 319 | * The rules apply equally to everyone in the community, no matter how much 320 | you've contributed. 321 | 322 | * Extreme violations of a threatening, abusive, destructive or illegal nature 323 | will be addressed immediately and are not subject to 3 strikes or forgiveness. 324 | 325 | * Contact [xuri.me](https://xuri.me) to report abuse or appeal violations. In the case of 326 | appeals, we know that mistakes happen, and we'll work with you to come up with a 327 | fair solution if there has been a misunderstanding. 328 | 329 | ## Coding Style 330 | 331 | Unless explicitly stated, we follow all coding guidelines from the Go 332 | community. While some of these standards may seem arbitrary, they somehow seem 333 | to result in a solid, consistent codebase. 334 | 335 | It is possible that the code base does not currently comply with these 336 | guidelines. We are not looking for a massive PR that fixes this, since that 337 | goes against the spirit of the guidelines. All new contributions should make a 338 | best effort to clean up and make the code base better than they left it. 339 | Obviously, apply your best judgement. Remember, the goal here is to make the 340 | code base easier for humans to navigate and understand. Always keep that in 341 | mind when nudging others to comply. 342 | 343 | The rules: 344 | 345 | 1. All code should be formatted with `gofmt -s`. 346 | 2. All code should pass the default levels of 347 | [`golint`](https://github.com/golang/lint). 348 | 3. All code should follow the guidelines covered in [Effective 349 | Go](http://golang.org/doc/effective_go.html) and [Go Code Review 350 | Comments](https://github.com/golang/go/wiki/CodeReviewComments). 351 | 4. Comment the code. Tell us the why, the history and the context. 352 | 5. Document _all_ declarations and methods, even private ones. Declare 353 | expectations, caveats and anything else that may be important. If a type 354 | gets exported, having the comments already there will ensure it's ready. 355 | 6. Variable name length should be proportional to its context and no longer. 356 | `noCommaALongVariableNameLikeThisIsNotMoreClearWhenASimpleCommentWouldDo`. 357 | In practice, short methods will have short variable names and globals will 358 | have longer names. 359 | 7. No underscores in package names. If you need a compound name, step back, 360 | and re-examine why you need a compound name. If you still think you need a 361 | compound name, lose the underscore. 362 | 8. No utils or helpers packages. If a function is not general enough to 363 | warrant its own package, it has not been written generally enough to be a 364 | part of a util package. Just leave it unexported and well-documented. 365 | 9. All tests should run with `go test` and outside tooling should not be 366 | required. No, we don't need another unit testing framework. Assertion 367 | packages are acceptable if they provide _real_ incremental value. 368 | 10. Even though we call these "rules" above, they are actually just 369 | guidelines. Since you've read all the rules, you now know that. 370 | 371 | If you are having trouble getting into the mood of idiomatic Go, we recommend 372 | reading through [Effective Go](https://golang.org/doc/effective_go.html). The 373 | [Go Blog](https://blog.golang.org) is also a great resource. Drinking the 374 | kool-aid is a lot easier than going thirsty. 375 | -------------------------------------------------------------------------------- /LICENSE: -------------------------------------------------------------------------------- 1 | The MIT License (MIT) 2 | 3 | Copyright (c) 2016 - 2020 Ri Xu All rights reserved. 4 | 5 | Permission is hereby granted, free of charge, to any person obtaining a copy of 6 | this software and associated documentation files (the "Software"), to deal in 7 | the Software without restriction, including without limitation the rights to 8 | use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of 9 | the Software, and to permit persons to whom the Software is furnished to do so, 10 | subject to the following conditions: 11 | 12 | The above copyright notice and this permission notice shall be included in all 13 | copies or substantial portions of the Software. 14 | 15 | THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR 16 | IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS 17 | FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR 18 | COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER 19 | IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN 20 | CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | GLC (glog cleaner) 2 | 3 | # GLC (glog cleaner) 4 | 5 | [![Build Status](https://travis-ci.com/xuri/glc.svg?branch=master)](https://travis-ci.com/xuri/glc) 6 | [![Code Coverage](https://codecov.io/gh/xuri/glc/branch/master/graph/badge.svg)](https://codecov.io/gh/xuri/glc) 7 | [![Go Report Card](https://goreportcard.com/badge/github.com/xuri/glc)](https://goreportcard.com/report/github.com/xuri/glc) 8 | [![go.dev](https://img.shields.io/badge/go.dev-reference-007d9c?logo=go&logoColor=white)](https://pkg.go.dev/github.com/xuri/glc) 9 | [![license](https://img.shields.io/github/license/mashape/apistatus.svg?maxAge=2592000)](https://github.com/xuri/glc/blob/master/LICENSE) 10 | [![Donate](https://img.shields.io/badge/Donate-PayPal-green.svg)](https://www.paypal.me/xuri) 11 | [![FOSSA Status](https://app.fossa.io/api/projects/git%2Bgithub.com%2Fxuri%2Fglc.svg?type=shield)](https://app.fossa.io/projects/git%2Bgithub.com%2Fxuri%2Fglc?ref=badge_shield) 12 | 13 | ## Overview 14 | 15 | GLC (glog cleaner) is a log clear for glog written in Go. This library support for deleting old logs. There are tools which can be run to do the cleanup such as logrotate, but logrotate can't runs on Windows and embedded system, so we need a cross platform library to rotate the log. 16 | 17 | ## Installation 18 | 19 | ```go 20 | go get github.com/xuri/glc 21 | ``` 22 | 23 | ## Usage 24 | 25 | Here is a example usage that will do check every hour and clean the log files that creation time older than 30 minutes. 26 | 27 | ```go 28 | glc.NewGLC(glc.InitOption{ 29 | Path: path, 30 | Prefix: `glc`, 31 | Interval: time.Duration(time.Hour), 32 | Reserve: time.Duration(time.Minute * 30), 33 | }) 34 | ``` 35 | 36 | ## Contributing 37 | 38 | Contributions are welcome! Open a pull request to fix a bug, or open an issue to discuss a new feature or change. 39 | 40 | ## Licenses 41 | 42 | This program is under the terms of the MIT License. See [LICENSE](https://github.com/xuri/glc/blob/master/LICENSE) for the full license text. 43 | 44 | 45 | [![FOSSA Status](https://app.fossa.io/api/projects/git%2Bgithub.com%2Fxuri%2Fglc.svg?type=large)](https://app.fossa.io/projects/git%2Bgithub.com%2Fxuri%2Fglc?ref=badge_large) -------------------------------------------------------------------------------- /README_zh.md: -------------------------------------------------------------------------------- 1 | GLC (glog cleaner) 2 | 3 | # GLC (glog cleaner) 4 | 5 | [![Build Status](https://travis-ci.com/xuri/glc.svg?branch=master)](https://travis-ci.com/xuri/glc) 6 | [![Code Coverage](https://codecov.io/gh/xuri/glc/branch/master/graph/badge.svg)](https://codecov.io/gh/xuri/glc) 7 | [![Go Report Card](https://goreportcard.com/badge/github.com/xuri/glc)](https://goreportcard.com/report/github.com/xuri/glc) 8 | [![go.dev](https://img.shields.io/badge/go.dev-reference-007d9c?logo=go&logoColor=white)](https://pkg.go.dev/github.com/xuri/glc) 9 | [![license](https://img.shields.io/github/license/mashape/apistatus.svg?maxAge=2592000)](https://github.com/xuri/glc/blob/master/LICENSE) 10 | [![Donate](https://img.shields.io/badge/Donate-PayPal-green.svg)](https://www.paypal.me/xuri) 11 | 12 | ## 简介 13 | 14 | GLC (glog cleaner) 是 Go 语言编写的 glog 日志清理类库，[glog](https://github.com/golang/glog) 是由 Google 开发的一个应用级日志框架，提供了日志分级、文件切分等功能，但是暂未提供日志清理功能，配合 GLC 可以方便地实现日志清理功能，类库提供了自定义日志保留时间、日志文件名前缀匹配和清理扫描频率的支持。 15 | 16 | ## 安装 17 | 18 | ```go 19 | go get github.com/xuri/glc 20 | ``` 21 | 22 | ## 使用方式 23 | 24 | 下面是一个简单的例子，每小时清理日志，仅保留 30 分钟内指定目录下以 glc 做前缀由 glog 产生的日志： 25 | 26 | ```go 27 | glc.NewGLC(glc.InitOption{ 28 | Path: path, 29 | Prefix: `glc`, 30 | Interval: time.Duration(time.Hour), 31 | Reserve: time.Duration(time.Minute * 30), 32 | }) 33 | ``` 34 | 35 | ## 社区合作 36 | 37 | 欢迎您为此项目贡献代码，提出建议或问题、修复 Bug 以及参与讨论对新功能的想法。 38 | 39 | ## 开源许可 40 | 41 | 本项目遵循 MIT 开源许可协议，访问 [LICENSE](https://github.com/xuri/glc/blob/master/LICENSE) 查看许可协议文件。 42 | -------------------------------------------------------------------------------- /SECURITY.md: -------------------------------------------------------------------------------- 1 | # Security Policy 2 | 3 | ## Supported Versions 4 | 5 | We will dive into any security-related issue as long as your glc version is still supported by us. When reporting an issue, include as much information as possible, but no need to fill fancy forms or answer tedious questions. Just tell us what you found, how to reproduce it, and any concerns you have about it. We will respond as soon as possible and follow up with any missing information. 6 | 7 | ## Reporting a Vulnerability 8 | 9 | Please e-mail us directly at `xuri.me@gmail.com` or use the security issue template on GitHub. In general, public disclosure is made after the issue has been fully identified and a patch is ready to be released. A security issue gets the highest priority assigned and a reply regarding the vulnerability is given within a typical 24 hours. Thank you! 10 | -------------------------------------------------------------------------------- /codelingo.yaml: -------------------------------------------------------------------------------- 1 | tenets: 2 | - import: codelingo/effective-go 3 | - import: codelingo/code-review-comments 4 | -------------------------------------------------------------------------------- /glc.go: -------------------------------------------------------------------------------- 1 | package glc 2 | 3 | import ( 4 | "io/ioutil" 5 | "os" 6 | "strings" 7 | "time" 8 | 9 | "github.com/golang/glog" 10 | ) 11 | 12 | type severity int32 // sync/atomic int32 13 | 14 | // identical to glog log severities 15 | const ( 16 | infoLog severity = iota 17 | warningLog 18 | errorLog 19 | fatalLog 20 | numSeverity = 4 21 | ) 22 | 23 | var severityName = []string{ 24 | infoLog: "INFO", 25 | warningLog: "WARNING", 26 | errorLog: "ERROR", 27 | fatalLog: "FATAL", 28 | } 29 | 30 | var empty = struct{}{} 31 | 32 | // GLC define the glog cleaner options: 33 | // 34 | // path - Log files will be clean to this directory 35 | // prefix - Log files name prefix 36 | // interval - Log files clean scanning interval 37 | // reserve - Log files reserve time 38 | // 39 | type GLC struct { 40 | path string 41 | prefix string 42 | interval time.Duration 43 | reserve time.Duration 44 | symlinks map[string]struct{} 45 | } 46 | 47 | // InitOption define the glog cleaner init options for glc: 48 | // 49 | // Path - Log files will be clean to this directory 50 | // Prefix - Log files name prefix 51 | // Interval - Log files clean scanning interval 52 | // Reserve - Log files reserve time 53 | // 54 | type InitOption struct { 55 | Path string 56 | Prefix string 57 | Interval time.Duration 58 | Reserve time.Duration 59 | } 60 | 61 | // NewGLC create a cleaner in a goroutine and do instantiation GLC by given 62 | // init options. 63 | func NewGLC(option InitOption) *GLC { 64 | c := new(GLC) 65 | c.path = option.Path 66 | c.interval = option.Interval 67 | c.prefix = option.Prefix 68 | c.reserve = option.Reserve 69 | c.symlinks = make(map[string]struct{}, numSeverity) 70 | 71 | for i := 0; i < numSeverity; i++ { 72 | symlink := c.prefix + "." + severityName[i] 73 | c.symlinks[symlink] = empty 74 | } 75 | 76 | go c.cleaner() 77 | return c 78 | } 79 | 80 | // clean provides function to check path exists by given log files path. 81 | func (c *GLC) clean() { 82 | exists, err := c.exists(c.path) 83 | if err != nil { 84 | glog.Errorln(err) 85 | return 86 | } 87 | if !exists { 88 | return 89 | } 90 | 91 | files, err := ioutil.ReadDir(c.path) 92 | if err != nil { 93 | glog.Errorln(err) 94 | return 95 | } 96 | c.check(files) 97 | } 98 | 99 | // exists returns whether the given file or directory exists or not 100 | func (c *GLC) exists(path string) (bool, error) { 101 | _, err := os.Stat(path) 102 | if err == nil { 103 | return true, nil 104 | } 105 | if os.IsNotExist(err) { 106 | return false, nil 107 | } 108 | return true, err 109 | } 110 | 111 | // check provides function to check log files name whether the deletion 112 | // condition is satisfied. 113 | func (c *GLC) check(files []os.FileInfo) { 114 | excludes := make(map[string]struct{}, numSeverity) 115 | for _, f := range files { 116 | // skip the destination of symlink files 117 | if _, ok := c.symlinks[f.Name()]; ok && f.Mode()&os.ModeSymlink != 0 { 118 | if dst, err := os.Readlink(c.path + f.Name()); err == nil { 119 | excludes[dst] = empty 120 | } 121 | } 122 | } 123 | 124 | for _, f := range files { 125 | if _, ok := excludes[f.Name()]; ok { 126 | continue 127 | } 128 | 129 | prefix := strings.HasPrefix(f.Name(), c.prefix) 130 | str := strings.Split(f.Name(), `.`) 131 | if prefix && len(str) == 7 && str[3] == `log` { 132 | c.drop(f) 133 | } 134 | } 135 | } 136 | 137 | // drop check the log file creation time and delete the file if the conditions 138 | // are met. 139 | func (c *GLC) drop(f os.FileInfo) { 140 | if time.Since(f.ModTime()) > c.reserve { 141 | err := os.Remove(c.path + f.Name()) 142 | if err != nil { 143 | glog.Errorln(err) 144 | } 145 | } 146 | } 147 | 148 | // cleaner provides regular cleaning function by given log files clean 149 | // scanning interval. 150 | func (c *GLC) cleaner() { 151 | for { 152 | c.clean() 153 | time.Sleep(c.interval) 154 | } 155 | } 156 | -------------------------------------------------------------------------------- /glc.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/xuri/glc/456f1e7078aca011012dbfe30d1abbda66e317a8/glc.png -------------------------------------------------------------------------------- /glc_test.go: -------------------------------------------------------------------------------- 1 | package glc 2 | 3 | import ( 4 | "os" 5 | "path/filepath" 6 | "testing" 7 | "time" 8 | ) 9 | 10 | func TestGLC(t *testing.T) { 11 | files := []string{"glc.localhost.xuri.log.WARNING.20180312-144710.3877", "glc.localhost.xuri.log.WARNING.20180312-144710"} 12 | path, err := filepath.Abs(filepath.Dir(os.Args[0])) 13 | if err != nil { 14 | t.Error(err) 15 | return 16 | } 17 | path += `/` 18 | 19 | go func() { 20 | glc := NewGLC(InitOption{ 21 | Path: path, 22 | Prefix: `glc`, 23 | Interval: time.Duration(time.Second), 24 | Reserve: time.Duration(time.Second * 3), 25 | }) 26 | glc.exists(files[0]) 27 | }() 28 | 29 | for _, file := range files { 30 | fp, err := os.OpenFile(path+file, os.O_CREATE|os.O_RDWR, 0700) 31 | if err != nil { 32 | fp.Close() 33 | t.Error(err) 34 | continue 35 | } 36 | _, err = fp.WriteAt([]byte{0}, 10) 37 | if err != nil { 38 | fp.Close() 39 | t.Error(err) 40 | continue 41 | } 42 | fp.Close() 43 | time.Sleep(time.Second * 5) 44 | } 45 | } 46 | 47 | func TestBadPath(t *testing.T) { 48 | path := []string{"", "/usr/bin/nohup"} 49 | for _, p := range path { 50 | go func(p string) { 51 | NewGLC(InitOption{ 52 | Path: p, 53 | Prefix: `glc`, 54 | Interval: time.Duration(time.Second), 55 | Reserve: time.Duration(time.Second * 3), 56 | }) 57 | }(p) 58 | } 59 | time.Sleep(time.Second * 5) 60 | } 61 | -------------------------------------------------------------------------------- /go.mod: -------------------------------------------------------------------------------- 1 | module github.com/xuri/glc 2 | 3 | go 1.12 4 | -------------------------------------------------------------------------------- /logo.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/xuri/glc/456f1e7078aca011012dbfe30d1abbda66e317a8/logo.png --------------------------------------------------------------------------------