From 16406b4cd48f054749ad6a039a8a5728fc858b15 Mon Sep 17 00:00:00 2001 From: Xiangce Liu Date: Sun, 29 Sep 2024 20:34:02 +0800 Subject: [PATCH 1/3] fix: datasource passed unicode to foreach_execute in py26 (#4232) - when collecting in py26 env, if the foreach_execute specs depends on DatasourceProvider, the provider will be in unicode type and causes the followed validate() fail - this change converted the unicode to string by force for all 'cmd' passed to CommandOutputProvider Signed-off-by: Xiangce Liu rh-pre-commit.version: 2.3.1 rh-pre-commit.check-secrets: ENABLED --- insights/core/spec_factory.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/insights/core/spec_factory.py b/insights/core/spec_factory.py index 9b1de9ad07..2abf7e14f1 100644 --- a/insights/core/spec_factory.py +++ b/insights/core/spec_factory.py @@ -940,7 +940,7 @@ def __init__(self, cmd, provider, save_as=None, context=HostContext, deps=None, split=True, keep_rc=False, timeout=None, inherit_env=None, override_env=None, signum=None, **kwargs): deps = deps if deps is not None else [] - self.cmd = cmd + self.cmd = cmd if six.PY3 else str(cmd) self.provider = provider self.save_as = save_as.strip("/") if save_as else None # strip as a relative file path self.context = context From 9f7640f276ec1e8b160c942fcf856301bd7653b7 Mon Sep 17 00:00:00 2001 From: Xiangce Liu Date: Wed, 25 Sep 2024 10:21:54 +0800 Subject: [PATCH 2/3] doc: Update the contributing guidance Signed-off-by: Xiangce Liu rh-pre-commit.version: 2.3.1 rh-pre-commit.check-secrets: ENABLED --- CONTRIBUTING.md | 57 ++++++++++++++++++++++++++----------------------- 1 file changed, 30 insertions(+), 27 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 927e34ac6c..6e2d86bdfa 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -27,20 +27,23 @@ Or, alternatively, using HTTPS: Initialize a virtualenv: cd insights-core - virtualenv . + python3 -m venv .python3 + source .python3/bin/activate + pip install --upgrade pip Install the project and its dependencies: - bin/pip install -e . + pip install -e . Install a rule repository: - bin/pip install -e path/to/rule/repo + pip install -e path/to/rule/repo ## Contributor Setup -If you wish to contribute to the insights-core project you'll need to create a fork in github. +If you wish to contribute to the insights-core project you'll need to create a +fork in GitHub. 1. Clone your fork: @@ -56,22 +59,11 @@ using the following commands: git pull upstream master git push origin master -### Python 2 - -To get the project setup for Python 2, use the following commands - - mkdir .python2 - virtualenv .python2 # Make sure you're using the python2 runtime - source .python2/bin/activate - pip install --upgrade pip - pip install -e .[develop] +### Python +To setup the project virtualenv, use the following commands -### Python 3 - -To setup the project for Python 3, use the following commands - - mkdir .python3 + cd insights-core python3 -m venv .python3 source .python3/bin/activate pip install --upgrade pip @@ -92,7 +84,7 @@ And they can be found under `docs/_build/html`. ## Contributor Submissions -Contributors should submit changes to the code via github "Pull +Contributors should submit changes to the code via GitHub "Pull Requests." One would normally start a new contribution with a branch from the current master branch of the upstream project. @@ -101,9 +93,9 @@ from the current master branch of the upstream project. 2. Make a branch on the fork. Use a branch name that would be meaningful as it will be part of a default commit message when the topic branch is merged into the upstream project - + git checkout -b your-topic - + 3. Make contributions on the topic branch. This project uses the [DCO](https://developercertificate.org/) to manage contributions. Commits must be signed by you in order to be accepted. To sign a commit simply add @@ -133,7 +125,7 @@ from the current master branch of the upstream project. of the topic branch. Again, such manipulations change history and require a `--force` push. -6. When ready, use the github UI to submit a pull request. Fill out +6. When ready, use the GitHub UI to submit a pull request. Fill out the information requested in the PR template. If your PR fixes an issue make sure to reference the issue using a [keyword](https://docs.github.com/en/issues/tracking-your-work-with-issues/creating-issues/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword) @@ -206,17 +198,24 @@ The following checklist is used when reviewing pull requests ### General (all submissions) - Commit messages are useful and properly formatted +- No sensitive personally identifiable information (PII) is included - Unit tests validate the code submission - One commit, or at most only a handful. More than five commits should be heavily questioned +#### About sensitive PII +- To find out more about sensitive PII, refer to + [Sensitive PII versus non-sensitive PII](https://www.ibm.com/topics/pii#Sensitive+PII+versus+non-sensitive+PII) +- [Gitleaks Action](https://github.com/gitleaks/gitleaks-action) is used in + insights-core to prevent hard-coded sensitive PII from leaking. + -### Parsers +### Component (Datasources, Components, Parsers, and Combiners) -- Parser is properly documented and should include: +- Component is properly documented and should include: - Example input - - The resulting data structure represented by the parser - - Parser usage is clear to a user with some knowledge of the domain + - The resulting data structure represented by the component + - Component usage is clear to a user with some knowledge of the domain without needing to examine the code itself - Meaning and usage of an "empty" (falsy data object) is clear @@ -224,6 +223,10 @@ The following checklist is used when reviewing pull requests reasonable examples of input data. Test data should be usable in the generation in archives used for integration testing and product demonstrations. + - 100% branch coverage is recommended + - [Codecov Actions](https://github.com/codecov/codecov-action) is used in + insights-core. You can check the project coverage report [here](https://app.codecov.io/gh/RedHatInsights/insights-core) + or check the PR's detailed coverage in your PR page. -- Parsers do not expose a ``defaultdict`` or any other data structure that +- Do not expose a ``defaultdict`` or any other data structure that would mutate as a side effect of accessing the object. From 55375dda95e29feba3dc56a34e97a600f0fe4eeb Mon Sep 17 00:00:00 2001 From: Xiangce Liu Date: Mon, 30 Sep 2024 14:05:06 +0800 Subject: [PATCH 3/3] update the guidance per feedback Signed-off-by: Xiangce Liu rh-pre-commit.version: 2.3.1 rh-pre-commit.check-secrets: ENABLED --- CONTRIBUTING.md | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 6e2d86bdfa..30c5fc9378 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -198,16 +198,17 @@ The following checklist is used when reviewing pull requests ### General (all submissions) - Commit messages are useful and properly formatted -- No sensitive personally identifiable information (PII) is included +- No sensitive personally identifiable information (PII) is included in any + types of files nor docstring - Unit tests validate the code submission - One commit, or at most only a handful. More than five commits should be heavily questioned -#### About sensitive PII +#### About Sensitive PII - To find out more about sensitive PII, refer to - [Sensitive PII versus non-sensitive PII](https://www.ibm.com/topics/pii#Sensitive+PII+versus+non-sensitive+PII) + [Sensitive vs. Nonsensitive PII](https://www.investopedia.com/terms/p/personally-identifiable-information-pii.asp#toc-sensitive-vs-nonsensitive-pii) - [Gitleaks Action](https://github.com/gitleaks/gitleaks-action) is used in - insights-core to prevent hard-coded sensitive PII from leaking. + insights-core to prevent hard-coded sensitive PII leak ### Component (Datasources, Components, Parsers, and Combiners) @@ -224,7 +225,7 @@ The following checklist is used when reviewing pull requests generation in archives used for integration testing and product demonstrations. - 100% branch coverage is recommended - - [Codecov Actions](https://github.com/codecov/codecov-action) is used in + - [Codecov Action](https://github.com/codecov/codecov-action) is used in insights-core. You can check the project coverage report [here](https://app.codecov.io/gh/RedHatInsights/insights-core) or check the PR's detailed coverage in your PR page.