Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

⚠️ CONFLICT! Lineage pull request for: skeleton #9

Draft
wants to merge 86 commits into
base: develop
Choose a base branch
from

Conversation

cisagovbot
Copy link

Lineage Pull Request: CONFLICT

Achtung!!!

Lineage has created this pull request to incorporate new changes found in an
upstream repository:

Upstream repository: https://github.com/cisagov/skeleton-python-library.git
Remote branch: HEAD

Check the changes in this pull request to ensure they won't cause issues with
your project.

The lineage/skeleton branch has one or more unresolved merge conflicts
that you must resolve before merging this pull request!

How to resolve the conflicts

  1. Take ownership of this pull request by removing any other assignees.

  2. Clone the repository locally, and reapply the merge:

    git clone [email protected]:cisagov/cyhy-db.git cyhy-db
    cd cyhy-db
    git remote add skeleton https://github.com/cisagov/skeleton-python-library.git
    git remote set-url --push skeleton no_push
    git switch develop
    git switch --create lineage/skeleton --track origin/develop
    git pull skeleton HEAD
    git status
  3. Review the changes displayed by the status command. Fix any conflicts and
    possibly incorrect auto-merges.

  4. After resolving each of the conflicts, add your changes to the
    branch, commit, and push your changes:

    git add .github/workflows/build.yml pytest.ini setup-env setup.py src/example/example.py tests/test_example.py 
    git commit
    git push --force --set-upstream origin lineage/skeleton

    Note that you may append to the default merge commit message
    that git creates for you, but please do not delete the existing
    content
    . It provides useful information about the merge that is
    being performed.

  5. Wait for all the automated tests to pass.

  6. Confirm each item in the "Pre-approval checklist" below.

  7. Remove any of the checklist items that do not apply.

  8. Ensure every remaining checkbox has been checked.

  9. Mark this draft pull request "Ready for review".

✅ Pre-approval checklist

Remove any of the following that do not apply. If you're unsure about
any of these, don't hesitate to ask. We're here to help!

  • ✌️ The conflicts in this pull request have been resolved.
  • All future TODOs are captured in issues, which are referenced
    in code comments.
  • All relevant type-of-change labels have been added.
  • All relevant repo and/or project documentation has been updated
    to reflect the changes in this PR.
  • Tests have been added and/or modified to cover the changes in this PR.
  • All new and existing tests pass.

✅ Pre-merge checklist

Remove any of the following that do not apply. These boxes should
remain unchecked until the pull request has been approved.

  • Bump major, minor, patch, or pre-release version as
    appropriate

    via the bump_version.sh script if this repository is
    versioned and the changes in this PR warrant a version
    bump
    .
  • Finalize version.

✅ Post-merge checklist

Remove any of the following that do not apply.

  • Create a release.

Note

You are seeing this because one of this repository's maintainers has
configured Lineage to open pull requests.

For more information:

🛠 Lineage configurations for this project are stored in .github/lineage.yml

📚 Read more about Lineage

Michael Saki and others added 30 commits February 14, 2024 12:59
This commit will make a few changes. The
orginal version of the semantic checking
function was a bit more difficult to read.
It is now somewhat easier to follow how
the regex is structured. Also the function
has been renamed to check_python_version
since it has 2 functions, making sure that
the version is semantically correct and the
second is to make sure that it is installed
on the user's machine. This makes it easier
to follow the logic for the flags, -p or
--python-version and -l or --list-versions
This commit will make a few changes. The
orginal version of the semantic checking
function was a bit more difficult to read.
It is now somewhat easier to follow how
the regex is structured. Also the function
has been renamed to check_python_version
since it has 2 functions, making sure that
the version is semantically correct and the
second is to make sure that it is installed
on the user's machine. This makes it easier
to follow the logic for the flags, -p or
--python-version and -l or --list-versions
Co-authored-by: dav3r <[email protected]>
Add the `check-useless-excludes` meta hook to verify that any defined
`exclude` directives apply to at least one file in the repository.
Instead of manually installing Packer we can instead leverage the
hashicorp/setup-packer Action just as we do for Terraform.
He is no longer a member of @cisagov/vm-dev.
Previously we only provided a lower bound for the version, but pinning to a specific version aligns with what has been done with the prettier hook and how pre-commit hooks are pinned in general.

The flake8-docstrings package is rarely updated, so there is no real downside to pinning to a specific version.

Co-authored-by: Nick <[email protected]>
This flag forces mypy to hide the errors about missing stubs and
instead simply install stubs without asking for confirmation.  It also
does not return an error code, which it does without this flag even if
you opt to let it install the missing type stubs.
Bumps [actions/cache](https://github.com/actions/cache) from 3 to 4.
- [Release notes](https://github.com/actions/cache/releases)
- [Changelog](https://github.com/actions/cache/blob/main/RELEASES.md)
- [Commits](actions/cache@v3...v4)

---
updated-dependencies:
- dependency-name: actions/cache
  dependency-type: direct:production
  update-type: version-update:semver-major
...

Signed-off-by: dependabot[bot] <[email protected]>
Bumps [crazy-max/ghaction-github-status](https://github.com/crazy-max/ghaction-github-status) from 3 to 4.
- [Release notes](https://github.com/crazy-max/ghaction-github-status/releases)
- [Commits](crazy-max/ghaction-github-status@v3...v4)

---
updated-dependencies:
- dependency-name: crazy-max/ghaction-github-status
  dependency-type: direct:production
  update-type: version-update:semver-major
...

Signed-off-by: dependabot[bot] <[email protected]>
* Use long flag names when possible
* Enable debug logging
* Add a helpful explanatory comment

Co-authored-by: felddy <[email protected]>
This is done automatically with the `pre-commit autoupdate` command.
The pre-commit/mirrors-prettier hook was manually held back because the
latest tags are for alpha releases of the next major version.
Use the latest v3 release available from NPM.
…max/ghaction-github-status-4

Bump crazy-max/ghaction-github-status from 3 to 4
Use an Action to install Packer in our GitHub Actions workflows
…hon-version-checks

Add checks for correct semantic version of Python
The pip-audit tool will audit any supplied pip requirements files for
vulnerable packages.
jsf9k and others added 24 commits October 31, 2024 13:19
Add a directive for hashicorp/setup-packer that was missed when it was
added to the `build` workflow. Add a directive for
cisagov/setup-env-github-action that is not strictly necessary since we
currently just pull from the `develop` branch, but is good to have in
case we were to change that in the future.
This is being done because the pip-audit pre-commit hook identifies a
vulnerability in ansible-core version 2.16.13.  Note that this
requires that we bump up ansible to version 10 since all versions of
ansible 9 have a dependency on ~=2.16.X.
Version 24.10.0 is the first version that supports Fedora 41 as a
valid platform.
The pin of ansible-core was originally put in place because the
pip-audit pre-commit hook identifies a vulnerability in ansible-core
2.16.13.  Normally we would pin ansible-core to >2.16.13, but in the
spirit of the earlier, optional pin of ansible>=10 we pin ansible-core
to >=2.17.  This effectively also pins ansible to >=10.

Co-authored-by: Nick M <[email protected]>
This adds even more evidence for why it is a good idea to go ahead and
upgrade ansible and ansible-core, in addition to the vulnerability
that pip-audit turned up.

Co-authored-by: Nick M <[email protected]>
…n-for-ansible-core

Bump up the lower bound on `ansible-core`
…-pre-commit-hook-version

Update the version of the `ansible-lint` `pre-commit` hook
Add the `--non-interactive` flag when installing type stubs via `mypy`
⚠️ CONFLICT! Lineage pull request for: skeleton
…/skeleton

# Conflicts:
#	.github/workflows/build.yml
#	pytest.ini
#	setup-env
#	setup.py
#	src/example/example.py
#	tests/test_example.py
@cisagovbot cisagovbot added the upstream update This issue or pull request pulls in upstream updates label Jan 31, 2025
# Access some data from our package data (see the setup.py)
secret_message: str = (
pkg_resources.resource_string("example", "data/secret.txt")
.decode("utf-8")

Check failure

Code scanning / CodeQL

Clear-text logging of sensitive information High

This expression logs
sensitive data (secret)
as clear text.

Copilot Autofix AI about 13 hours ago

To fix the problem, we should avoid logging the content of secret_message directly. Instead, we can log a message indicating that the secret message was accessed without revealing its content. This way, we maintain the functionality of logging the event without exposing sensitive information.

  • Replace the line that logs the secret_message with a line that logs a generic message indicating that the secret message was accessed.
  • Ensure that the new log message does not contain any sensitive information.
Suggested changeset 1
src/example/example.py

Autofix patch

Autofix patch
Run the following command in your local git repository to apply this patch
cat << 'EOF' | git apply
diff --git a/src/example/example.py b/src/example/example.py
--- a/src/example/example.py
+++ b/src/example/example.py
@@ -102,3 +102,3 @@
     )
-    logging.info('Secret="%s"', secret_message)
+    logging.info('Secret message accessed successfully.')
 
EOF
@@ -102,3 +102,3 @@
)
logging.info('Secret="%s"', secret_message)
logging.info('Secret message accessed successfully.')

Copilot is powered by AI and may make mistakes. Always verify output.
Positive Feedback
Negative Feedback

Provide additional feedback

Please help us improve GitHub Copilot by sharing more details about this comment.

Please select one or more of the options
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
upstream update This issue or pull request pulls in upstream updates
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants