Prep to Open Source

.github/workflows/coverage.yaml

@@ -0,0 +1,35 @@
+
+name: Post Coverage Commit
+
+on:
+  workflow_run:
+    workflows: ["Pytest"]
+    types:
+      - completed
+
+jobs:
+  coverage:
+    runs-on: ubuntu-latest
+    if: github.event.workflow_run.event == "pull_request" && github.event.workflow_run.conclusion == "success"
+    permissions:
+      pull-requests: write
+      contents: write
+      actions: read
+    steps:
+    - uses: actions/checkout@v4
+
+    - uses: actions/download-artifact@v4
+      id: download
+      with:
+        pattern: coverage-*
+        merge-multiple: true
+    - name: Re-add relative so the action is happy
+      run: |
+        echo "[run]" >> .coveragerc
+        echo "relative_files = true" >> .coveragerc
+    - name: Python Coverage Comment
+      uses: py-cov-action/python-coverage-comment-action@b2eb38dd175bf053189b35f738f9207278b00925
+      with:
+        GITHUB_TOKEN: ${{ github.token }}
+        MERGE_COVERAGE_FILES: true
+        GITHUB_PR_RUN_ID: ${{ github.event.workflow_run.id }}

.github/workflows/matchers/ruff.json

@@ -0,0 +1,14 @@
+{
+  "problemMatcher": [
+    {
+      "owner": "ruff",
+      "pattern": [
+        {
+          "regexp": "^(Would reformat): (.+)$",
+          "message": 1,
+          "file": 2
+        }
+      ]
+    }
+  ]
+}

.github/workflows/package-quality-control.yaml

@@ -11,6 +11,8 @@ on:
 jobs:
   # Checks that version number has been updated
   package-quality-control:
+    permissions:
+      contents: read
     runs-on: ubuntu-latest
     steps:
       - name: Checkout Current PR Branch
@@ -19,7 +21,7 @@ jobs:
         uses: actions/setup-python@v5
       - name: Check for Changed Files
         id: changed-files
-        uses: tj-actions/changed-files@v44
+        uses: tj-actions/changed-files@635f118699dd888d737c15018cd30aff2e0274f8
         with:
           files: |
             pyproject.toml

.github/workflows/pyright.yaml

@@ -5,6 +5,8 @@
 
 jobs:
   pyright:
+    permissions:
+      contents: read
 
     runs-on: ubuntu-latest
     steps:
@@ -19,4 +21,4 @@
         hatch env create dev
     - run: echo "$(hatch env find dev)/bin" >> $GITHUB_PATH
     - name: Run pyright
-      uses: jakebailey/pyright-action@v2.3.1
+      uses: jakebailey/pyright-action@vb5d50e5cde6547546a5c4ac92e416a8c2c1a1dfe

.github/workflows/pytest.yaml

@@ -8,12 +8,17 @@ on:
 
 jobs:
   pytest:
+    permissions:
+      contents: read
 
     runs-on: ${{ matrix.os }}
     strategy:
       matrix:
-        os: [ubuntu-latest, macos-latest, windows-latest]
-        python-version: ["3.9", "3.10", "3.11", "pypy3.9", "pypy3.10"]
+        # pytest-forked does not work on windows and we currently use it for isolation
+        # of logging configs as logging.dictConfig has a setting to not disable old loggers
+        # but, does seem to trample old handlers, filters and formatters
+        os: [ubuntu-latest, macos-latest]
+        python-version: ["3.9", "3.10", "3.11", "3.12", "pypy3.9", "pypy3.10"]
         exclude:
           - os: macos-latest
             python-version: "3.9"
@@ -40,32 +45,10 @@ jobs:
         hatch run dev:pytest
       env:
         COVERAGE_FILE: ".coverage.${{ matrix.os }}.${{ matrix.python-version }}"
-    - name: Store coverage file
+    - name: Store Pull Request comment to be posted
       uses: actions/upload-artifact@v4
+      if: steps.coverage_comment.outputs.COMMENT_FILE_WRITTEN == 'true'
       with:
-        name: coverage-${{ matrix.os }}-${{ matrix.python-version }}
-        path: .coverage.${{ matrix.os }}.${{ matrix.python-version }}
-
-  coverage:
-    runs-on: ubuntu-latest
-    needs: pytest
-    permissions:
-      pull-requests: write
-      contents: write
-    steps:
-    - uses: actions/checkout@v4
-
-    - uses: actions/download-artifact@v4
-      id: download
-      with:
-        pattern: coverage-*
-        merge-multiple: true
-    - name: Re-add relative so the action is happy
-      run: |
-        echo "[run]" >> .coveragerc
-        echo "relative_files = true" >> .coveragerc
-    - name: Python Coverage Comment
-      uses: py-cov-action/[email protected]
-      with:
-        GITHUB_TOKEN: ${{ github.token }}
-        MERGE_COVERAGE_FILES: true
+        name: python-coverage-comment-action
+        path: python-coverage-comment-action.txt
+        include-hidden-files: true

.github/workflows/ruff.yaml

@@ -5,6 +5,8 @@ on:
 
 jobs:
   ruff:
+    permissions:
+      contents: read
 
     runs-on: ubuntu-latest
     steps:
@@ -17,6 +19,11 @@ jobs:
       run: |
         python -m pip install hatch
         hatch env create dev
-    - name: Lint with Ruff
+    - name: Lint with Ruff (check)
       run: |
-        hatch run dev:ruff --output-format=github .
+        hatch run dev:ruff check --output-format=github .
+    - name: Register problem matcher for ruff format
+      run: echo "::add-matcher::.github/workflows/matchers/ruff.json"
+    - name: Lint with Ruff (format)
+      run: |
+        hatch run dev:ruff format --check .

.pre-commit-config.yaml

@@ -8,7 +8,7 @@ repos:
   # Run the formatter.
   - id: ruff-format
 - repo: https://github.com/RobertCraigie/pyright-python
-  rev: v1.1.355
+  rev: v1.1.382
   hooks:
   - id: pyright
     # I don't love having to specify these here, but pre-commit only seems to work

CODE_OF_CONDUCT.md

@@ -0,0 +1,74 @@
+# Contributor Covenant Code of Conduct
+
+## Our Pledge
+
+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.
+
+## Our Standards
+
+Examples of behavior that contributes to creating a positive environment
+include:
+
+* Using welcoming and inclusive language
+* Being respectful of differing viewpoints and experiences
+* Gracefully accepting constructive criticism
+* Focusing on what is best for the community
+* Showing empathy towards other community members
+
+Examples of unacceptable behavior by participants include:
+
+* The use of sexualized language or imagery and unwelcome sexual attention or
+advances
+* Trolling, insulting/derogatory comments, and personal or political attacks
+* Public or private harassment
+* Publishing others' private information, such as a physical or electronic
+  address, without explicit permission
+* Other conduct which could reasonably be considered inappropriate in a
+  professional setting
+
+## Our Responsibilities
+
+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.
+
+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.
+
+## Scope
+
+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.
+
+## Enforcement
+
+Instances of abusive, harassing, or otherwise unacceptable behavior may be
+reported by contacting the project team at <[email protected]>. All
+complaints will be reviewed and investigated and will result in a response that
+is deemed necessary and 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.
+
+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.
+
+## Attribution
+
+This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4,
+available at [http://contributor-covenant.org/version/1/4][version]
+
+[homepage]: http://contributor-covenant.org
+[version]: http://contributor-covenant.org/version/1/4/

CONTRIBUTING.md

@@ -0,0 +1,43 @@
+## Contributing
+
+[fork]: https://github.com/github/annotated-logger/fork
+[pr]: https://github.com/github/annotated-logger/compare
+[style]: https://docs.astral.sh/ruff/
+
+Hi there! We're thrilled that you'd like to contribute to this project. Your help is essential for keeping it great.
+
+Contributions to this project are [released](https://help.github.com/articles/github-terms-of-service/#6-contributions-under-repository-license) to the public under the [project's open source license](LICENSE.txt).
+
+Please note that this project is released with a [Contributor Code of Conduct](CODE_OF_CONDUCT.md). By participating in this project you agree to abide by its terms.
+
+## Developing a fix/feature
+
+Annotated Logger uses `ruff`, `pytest`, `pyright` and `mutmut` for testing and linting. It uses [`hatch`](https://github.com/pypa/hatch) as a project manager to build and install dependencies. When developing locally it's suggested that you ensure that your editor supports `ruff` and `pyright` for inline linting. The `pytest` test suite is very quick and should be run frequently. (`mutmut`)[https://github.com/boxed/mutmut] is a mutation testing tool and is fairly slow as it runs the other three tools hundreds of times after making minor tweaks to the code. It will typically be run only once development is complete to ensure everything is fully tested.
+
+`script/mutmut_runner` is what `mutmut` uses to see if the mutation fails, however, it's also quite useful on it's own as it runs `ruff`, `pytest` and `pyright` exiting as soon as anything fails, so it makes a good sanity check.
+
+In addition to the tests and linting above all PRs will compare the version number in \_\_init\_\_.py with the version in `main` to ensure that new PRs results in new versions.
+
+## Submitting a pull request
+
+1. [Fork][fork] and clone the repository
+1. Configure and install the dependencies: `script/bootstrap`
+1. Make sure the tests pass on your machine: `hatch run dev:test`
+1. Make sure linting passes: `hatch run dev:lint` and `hatch run dev:typing`
+1. Create a new branch: `git checkout -b my-branch-name`
+1. Make your change, add tests, and make sure the tests still pass
+1. Push to your fork and [submit a pull request][pr]
+1. Pat yourself on the back and wait for your pull request to be reviewed and merged.
+
+Here are a few things you can do that will increase the likelihood of your pull request being accepted:
+
+- Follow the [style guide][style].
+- Write tests.
+- Keep your change as focused as possible. If there are multiple changes you would like to make that are not dependent upon each other, consider submitting them as separate pull requests.
+- Write a [good commit message](http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html).
+
+## Resources
+
+- [How to Contribute to Open Source](https://opensource.guide/how-to-contribute/)
+- [Using Pull Requests](https://help.github.com/articles/about-pull-requests/)
+- [GitHub Help](https://help.github.com)

LICENSE.txt

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright GitHub, Inc.
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

README.md

@@ -1,8 +1,18 @@
 # Annotated Logger
+
+[contribution]: https://github.com/github/annotated-logger/blob/main/CONTRIBUTING.md
+
 [![Coverage badge](https://github.com/github/logger-decorator/raw/python-coverage-comment-action-data/badge.svg)](https://github.com/github/logger-decorator/tree/python-coverage-comment-action-data) [![Ruff](https://img.shields.io/endpoint?url=https://raw.githubusercontent.com/astral-sh/ruff/main/assets/badge/v2.json)](https://github.com/astral-sh/ruff) [![Checked with pyright](https://microsoft.github.io/pyright/img/pyright_badge.svg)](https://microsoft.github.io/pyright/)
 
 The `annotated-logger` package provides a decorator that can inject a annotatable logger object into a method or class. This logger object is a drop in replacement for `logging.logger` with additional functionality.
 
+## Background
+
+Annotated Logger is actively used by GitHub's Vulnerability Management team to help to easily add context to our logs in splunk. It is more or less feature complete for our current use cases, but we will add additional features/fixes as we discover a need for them. But, we'd love feature requests, bug report and or PRs for either (see our [contribution guidelines][contribution] for more information if you wish to contribute).
+
+## Requirements
+Annotated Logger is a Python package. It should work on any version of Python 3, but it is currently tested on 3.9 and higher.
+
 ## Usage
 
 The `annotated-logger` package allows you to decorate a function so that the start and end of that function is logged as well as allowing that function to request an `annotated_logger` object which can be used as if it was a standard python `logger`. Additionally, the `annotated_logger` object will have added annotations based on the method it requested from, any other annotations that were configured ahead of time and any annotations that were added prior to a log being made. Finally, any uncaught exceptions in a decorated method will be logged and re-raised, which allows you to when and how a method ended regardless of if it was successful or not.
@@ -28,12 +38,9 @@ foo("this is the bar parameter")
 
 The example directory has a few files that exercise all of the features of the annotated-logger package. The `Calculator` class is the most fully featured example (but not a fully featured calculator :wink:). The `logging_config` example shows how to configure a logger via a dictConfig, like django uses. It also shows some of the interactions that can exist between a `logging` logger and an `annotated_logger` if `logging` is configured to use the annotated logger filter.
 
+## License
 
+This project is licensed under the terms of the MIT open source license. Please refer to MIT for the full terms.
 
-## Contributing
-
-Annotated Logger uses `ruff`, `pytest`, `pyright` and `mutmut` for testing and linting. It uses [`hatch`](https://github.com/pypa/hatch) as a project manager to build and install dependencies. When developing locally it's suggested that you ensure that your editor supports `ruff` and `pyright` for inline linting. The `pytest` test suite is very quick and should be run frequently. (`mutmut`)[https://github.com/boxed/mutmut] is a mutation testing tool and is fairly slow as it runs the other three tools hundreds of times after making minor tweaks to the code. It will typically be run only once development is complete to ensure everything is fully tested.
-
-`script/mutmut_runner` is what `mutmut` uses to see if the mutation fails, however, it's also quite useful on it's own as it runs `ruff`, `pytest` and `pyright` exiting as soon as anything fails, so it makes a good sanity check.
-
-In addition to the tests and linting above all PRs will compare the version number in \_\_init\_\_.py with the version in `main` to ensure that new PRs results in new versions.
+## Maintainers
+This project is primarily maintained by `crimsonknave` on behalf of GitHub's Vulnerability Management team as it was initially developed for our internal use.