| Age | Commit message (Collapse) | Author |
|---|
|
One test that will cause the build to fail if sizing is emitted on repeated
fields, and one test that verifies that sizing _is_ emitted on repeated
fields with fixed sizes.
|
|
This is more consistent with the C interface's naming convention.
|
|
F-strings aren't available in Python 2.
|
|
This adds a max_size field referring to the C #define, indicating the maximum
encoded size of that message type. If the size cannot be determined, for
example due to non-bounded repeated fields, the constant is omitted.
This closes #932
|
|
|
|
|
|
|
|
1.59 is the first grpcio-tools version with pre-built wheels for Python
3.12.
Setuptools before 66.1.0 was not compatible with Python 3.12 due to the
use of deprecated standard library classes.
|
|
|
|
|
|
|
|
With Bazel 7.0.0, nocopts has been removed and is no longer supported.
The correct way to handle this is to subtract features using the
`features` attribute (see bazelbuild/bazel#8706).
|
|
|
|
Add CodeQL Workflow for Code Security Analysis
This pull request introduces a CodeQL workflow to enhance the security analysis of our repository. CodeQL is a powerful static analysis tool that helps identify and mitigate security vulnerabilities in our codebase. By integrating this workflow into our GitHub Actions, we can proactively identify and address potential issues before they become security threats.
We added a new CodeQL workflow file (.github/workflows/codeql.yml) that
- Runs on every pull request (functionality to run on every push to main branches is included as a comment for convenience).
- Runs daily.
- Excludes queries with a high false positive rate or low-severity findings.
- Does not display results for git submodules, focusing only on our own codebase.
Testing:
To validate the functionality of this workflow, we have run several test scans on the codebase and reviewed the results. The workflow successfully compiles the project, identifies issues, and provides actionable insights while reducing noise by excluding certain queries and third-party code.
Deployment:
Once this pull request is merged, the CodeQL workflow will be active and automatically run on every push and pull request to the main branch. To view the results of these code scans, please follow these steps:
1. Under the repository name, click on the Security tab.
2. In the left sidebar, click Code scanning alerts.
Additional Information:
- You can further customize the workflow to adapt to your specific needs by modifying the workflow file.
- For more information on CodeQL and how to interpret its results, refer to the GitHub documentation and the CodeQL documentation (https://codeql.github.com/ and https://codeql.github.com/docs/).
Signed-off-by: Brian <bayuan@purdue.edu>
|
|
Add CodeQL Workflow for Code Security Analysis
This pull request introduces a CodeQL workflow to enhance the security analysis of our repository. CodeQL is a powerful static analysis tool that helps identify and mitigate security vulnerabilities in our codebase. By integrating this workflow into our GitHub Actions, we can proactively identify and address potential issues before they become security threats.
We added a new CodeQL workflow file (.github/workflows/codeql.yml) that
- Runs on every pull request (functionality to run on every push to main branches is included as a comment for convenience).
- Runs daily.
- Excludes queries with a high false positive rate or low-severity findings.
- Does not display results for git submodules, focusing only on our own codebase.
Testing:
To validate the functionality of this workflow, we have run several test scans on the codebase and reviewed the results. The workflow successfully compiles the project, identifies issues, and provides actionable insights while reducing noise by excluding certain queries and third-party code.
Deployment:
Once this pull request is merged, the CodeQL workflow will be active and automatically run on every push and pull request to the main branch. To view the results of these code scans, please follow these steps:
1. Under the repository name, click on the Security tab.
2. In the left sidebar, click Code scanning alerts.
Additional Information:
- You can further customize the workflow to adapt to your specific needs by modifying the workflow file.
- For more information on CodeQL and how to interpret its results, refer to the GitHub documentation and the CodeQL documentation (https://codeql.github.com/ and https://codeql.github.com/docs/).
Signed-off-by: Brian <bayuan@purdue.edu>
|
|
Add CodeQL Workflow for Code Security Analysis
This pull request introduces a CodeQL workflow to enhance the security analysis of our repository. CodeQL is a powerful static analysis tool that helps identify and mitigate security vulnerabilities in our codebase. By integrating this workflow into our GitHub Actions, we can proactively identify and address potential issues before they become security threats.
We added a new CodeQL workflow file (.github/workflows/codeql.yml) that
- Runs on every push and pull request to the main branch.
- Excludes queries with a high false positive rate or low-severity findings.
- Does not display results for third-party code, focusing only on our own codebase.
Testing:
To validate the functionality of this workflow, we have run several test scans on the codebase and reviewed the results. The workflow successfully compiles the project, identifies issues, and provides actionable insights while reducing noise by excluding certain queries and third-party code.
Deployment:
Once this pull request is merged, the CodeQL workflow will be active and automatically run on every push and pull request to the main branch. To view the results of these code scans, please follow these steps:
1. Under the repository name, click on the Security tab.
2. In the left sidebar, click Code scanning alerts.
Additional Information:
- You can further customize the workflow to adapt to your specific needs by modifying the workflow file.
- For more information on CodeQL and how to interpret its results, refer to the GitHub documentation and the CodeQL documentation.
Signed-off-by: Brian <bayuan@purdue.edu>
|
|
- Allow installed nanopb_generator.py wrapper script find the module by relative path.
- Install include files under `nanopb` subdirectory.
|
|
|
|
|
|
Makes the installation consistent with "pip install nanopb" results,
and avoids naming conflicts with other libraries.
|
|
|
|
It is better to define FT_CALLBACK manually at the point
where it makes sense, but the automatic logic avoids build
failures if you don't care about the details.
|
|
|
|
Uses NULL for pointer types and {} for other types.
User can override the type with generator option "initializer".
|
|
|
|
|
|
|
|
|
|
|
|
PyInstaller now puts libraries in a subdirectory.
Use --strip instead of manually stripping debug symbols.
Needed also changes in how builtin protoc include path is constructed.
|
|
|
|
|
|
names
|
|
|
|
|
|
|
|
versions
If only the minor and patch versions are found, assume the major version is 3.
|
|
|
|
Fix relative path passed to protoc when using RELPATH but
NANOPB_GENERATE_CPP_APPEND_PATH not set. In this case the path provided
by RELPATH should be passed to protoc first instead of the current
source directory.
This was working before and broke with 8cc860c.
Co-authored-by: Guillaume Lager <g.lager@innoseis.com>
|
|
These were needed by old versions of pyinstaller.
|
|
Allows building protos found in libraries by using ${PIOENV} substitutions like so:
`custom_nanopb_protos = +<.pio/libdeps/${PIOENV}/some_library/proto/*.proto>`
|
|
Bumps [grpcio](https://github.com/grpc/grpc) from 1.51.3 to 1.53.0.
- [Release notes](https://github.com/grpc/grpc/releases)
- [Changelog](https://github.com/grpc/grpc/blob/master/doc/grpc_release_schedule.md)
- [Commits](https://github.com/grpc/grpc/compare/v1.51.3...v1.53.0)
---
updated-dependencies:
- dependency-name: grpcio
dependency-type: direct:production
...
Signed-off-by: dependabot[bot] <support@github.com>
|
|
Protoc version number seems to have dropped the last number,
match only first two in the regexp.
|
|
|
|
|
|
|
|
Needed for NAME_WLE (see commit 9cdc4cf2104ba1592).
Thanks for Ilya Maykov for noticing.
|
|
|
|
|
|
|
