Update python-sdk commit to 1.19.0rc0#8500
Conversation
WalkthroughThe python_sdk submodule pointer was updated from commit 96c50517f826a49532456d3d134de6834326af7c to f73754901e272071e0b1b99263c7e10fc0e31f9a. This is a minimal change affecting only the submodule reference with no modifications to code logic, control flow, or APIs. 🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@python_sdk`:
- Line 1: The PR updates a Python dependency to the pre-release version
"1.19.0rc0" on the release-1.8 branch; replace that release-candidate version
with the corresponding stable release (e.g., "1.19.0" or the latest non-RC
patch) wherever "1.19.0rc0" is declared in the python_sdk package (requirements
file, pyproject.toml, setup.cfg/setup.py or similar) to ensure the release
branch depends only on stable releases; update any lockfile
(pipfile.lock/poetry.lock/requirements.txt.lock) accordingly and run dependency
install/lock commands to regenerate the lockfile.
- Line 1: The pyproject.toml currently sets version "1.19.0rc0" on the
release-1.8 branch which is an untagged, unreleased RC; update pyproject.toml to
reference a valid upstream tag (e.g., "1.18.1" or the official prerelease
"1.19.0b0") or create and push the corresponding git tag "v1.19.0rc0" and
release it upstream if you truly need that RC; additionally, after changing the
version, run a quick compatibility check for the branch-report change (Infrahub
>= 1.7) and presence of py.typed to catch potential type-checking or dependency
issues before merging.
| @@ -1 +1 @@ | |||
| Subproject commit 96c50517f826a49532456d3d134de6834326af7c | |||
| Subproject commit f73754901e272071e0b1b99263c7e10fc0e31f9a | |||
There was a problem hiding this comment.
Consider using a stable release instead of a release candidate.
The PR is targeting the release-1.8 branch but updating to a release candidate (1.19.0rc0). Release candidates are typically pre-release versions intended for testing and may contain bugs or incomplete features. For a release branch, it's generally recommended to use stable, fully tested versions.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@python_sdk` at line 1, The PR updates a Python dependency to the pre-release
version "1.19.0rc0" on the release-1.8 branch; replace that release-candidate
version with the corresponding stable release (e.g., "1.19.0" or the latest
non-RC patch) wherever "1.19.0rc0" is declared in the python_sdk package
(requirements file, pyproject.toml, setup.cfg/setup.py or similar) to ensure the
release branch depends only on stable releases; update any lockfile
(pipfile.lock/poetry.lock/requirements.txt.lock) accordingly and run dependency
install/lock commands to regenerate the lockfile.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Explore the repository structure and submodule configuration
echo "=== Repository structure ==="
ls -la | head -20
echo -e "\n=== Checking .gitmodules ==="
if [ -f .gitmodules ]; then
cat .gitmodules
else
echo ".gitmodules not found"
fi
echo -e "\n=== Git submodule status ==="
git config --file .gitmodules --name-only --get-regexp '^submodule\.'
echo -e "\n=== Checking if python_sdk is a submodule ==="
git ls-files -s | grep python_sdk
echo -e "\n=== Python_sdk directory info ==="
if [ -d python_sdk ]; then
echo "python_sdk directory exists"
ls -la python_sdk/ | head -10
if [ -f python_sdk/.git ]; then
echo "Contains .git directory"
fi
else
echo "python_sdk directory does not exist"
fi
echo -e "\n=== Git config submodule urls ==="
git config --file .gitmodules --get-regexp 'url'Repository: opsmill/infrahub
Length of output: 1904
🌐 Web query:
infrahub-sdk-python commit f73754901e272071e0b1b99263c7e10fc0e31f9a version tag
💡 Result:
Commit f73754901e272071e0b1b99263c7e10fc0e31f9a updates pyproject.toml to version 1.19.0rc0. [1]
As of Feb 27, 2026, there does not appear to be a Git tag/release named v1.19.0rc0 in opsmill/infrahub-sdk-python (it’s not present in the tag list, and the release URL returns 404). [2] [3]
Answer: 1.19.0rc0 (package version at that commit; no matching v1.19.0rc0 Git tag found). [1] [2]
References:
[1] opsmill/infrahub-sdk-python@f737549
[2] https://github.com/opsmill/infrahub-sdk-python/tags
[3] https://github.com/opsmill/infrahub-sdk-python/releases/tag/v1.19.0rc0
🌐 Web query:
infrahub-sdk-python 1.19.0rc0 release changelog breaking changes
💡 Result:
Status: no 1.19.0rc0 found
I could not find any infrahub-sdk / infrahub-sdk-python release/tag named 1.19.0rc0 on the upstream GitHub repo (releases/tags) or on PyPI. The newest 1.19.x pre-release visible upstream is v1.19.0b0 (Feb 18, 2026). [1]
On PyPI, the latest published version shown is 1.18.1 (Jan 9, 2026). [2]
Closest available changelog (GitHub): v1.19.0b0
Added
- Support for FileObject nodes, including file upload/download:
upload_from_path(path)upload_from_bytes(content, name)download_file(dest)(memory or stream-to-disk for large files) [1]
- Added
py.typedto enable downstream type checking; note this may surface new typing issues in consuming projects. [1]
Changed
- Branch report command now uses node metadata (instead of a deprecated relationship-based approach) for proposed-change creator info; requires Infrahub 1.7+. [1]
Fixed
- SDK tracking continues after delete errors when nodes were already deleted via cascade delete. [1]
Breaking changes
No explicit “Breaking changes” section is listed for v1.19.0b0; however, two items may be breaking depending on your environment:
- The branch report change requires Infrahub >= 1.7. [1]
- Shipping
py.typedcan introduce new mypy/typing failures in downstream projects. [1]
Sources: [1] [2]
Do not use untagged, unreleased RC version in release branch.
The commit f73754901e272071e0b1b99263c7e10fc0e31f9a sets pyproject.toml to version 1.19.0rc0, but there is no corresponding v1.19.0rc0 Git tag in the upstream repository. This means:
- Using an untagged/unreleased version in
release-1.8compromises reproducibility and traceability - The latest stable is
v1.18.1(Jan 2026); the latest pre-release isv1.19.0b0(Feb 2026) - Potential breaking changes in this version range: branch report command now requires Infrahub >= 1.7, and the addition of
py.typedmay trigger new type-checking failures in downstream projects
Use a tagged release (stable or beta) instead, or create a proper Git tag and release for v1.19.0rc0 if this version is necessary.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@python_sdk` at line 1, The pyproject.toml currently sets version "1.19.0rc0"
on the release-1.8 branch which is an untagged, unreleased RC; update
pyproject.toml to reference a valid upstream tag (e.g., "1.18.1" or the official
prerelease "1.19.0b0") or create and push the corresponding git tag "v1.19.0rc0"
and release it upstream if you truly need that RC; additionally, after changing
the version, run a quick compatibility check for the branch-report change
(Infrahub >= 1.7) and presence of py.typed to catch potential type-checking or
dependency issues before merging.
2 participants
Update
infrahub-sdkcommit reference to the first release candidate of 1.191.19.0rc0.Summary by CodeRabbit