Closed ff137 closed 6 months ago
Setting to draft as merging this to main will potentially break deployments that are pointing to use main as opposed to 1.7.2. We'd probably want a stable version release and/or tests for the repo before merging. Awaiting further discussion.
Thanks @ff137
@WadeBarnes is this something we can merge or are there concerns? I updated the branch to sync-up with main, but the PR will become stale (again) if we leave it as-is...
FWIW, I don't think any of the updates had breaking changes. But if there are no tests, only way to know is try fire up this branch locally and see if usual workflows still work.
I'd say adding a dependabot and a CICD GitHub workflow is the way to go
I get the following error when I run a ./manage rebuild
:
#8 6.577 ERROR: Could not find a version that satisfies the requirement aiohttp-jinja2~=1.5.1 (from versions: 0.0.0, 0.0.1, 0.0.2, 0.1.0, 0.2.1, 0.3.0, 0.3.1, 0.4.0, 0.4.1, 0.4.2, 0.4.3, 0.5.0, 0.6.1, 0.6.2, 0.7.0, 0.8.0, 0.12.0, 0.13.0, 0.14.0, 0.15.0, 0.16.0, 0.17.0, 1.0.0, 1.1.0, 1.1.1, 1.1.2, 1.2.0, 1.3.0, 1.4.0, 1.4.1, 1.4.2, 1.5)
#8 6.577 ERROR: No matching distribution found for aiohttp-jinja2~=1.5.1
@ff137 any chance you can follow-up on this and see if we can get the build/rebuild working again?
@esune will do! The main blocker for me was not having tests to know if the dependency upgrades have broken anything. I remember when I made this, reviewed the changelogs for major upgrades and didn't indicate anything should break. But you never know without tests!
So is the plan to just merge the upgrades, test the build manually, and revert if anything broke? I'll gladly get it up to date again, but just don't want to silently break something 🙃😄
I can run some tests on it once everything is building.
@WadeBarnes can those tests be written in a yaml file for an automated GitHub workflow? If it's simple steps, GPT can translate it in no time.
Manual testing unfortunately.
What, how? Surely any manual steps can be automated. Because how is a codebase maintainable without automated tests?
I'd happily write the workflow if I knew anything about the functionality that ought to be tested
@esune @WadeBarnes I've rebased this PR, with latest dependency upgrades (incl for indy_vdr)
The reason that previously No matching distribution found for aiohttp-jinja2~=1.5.1
, is because the base image being used in the docker file is running python 3.6.13 ... now, even 3.7 is end-of-life since mid 2023. So I included a manual installation of python 3.8 in the dockerfile. It may be worth updating the base image include a newer python version instead.
Upgrading to 3.10 should probably be the way to go ... 3.11/3.12 may have some breaking changes, but I guess 3.10 would work fine and then we're good til 2026!
What, how? Surely any manual steps can be automated. Because how is a codebase maintainable without automated tests?
I'd happily write the workflow if I knew anything about the functionality that ought to be tested
The updates you've made are related to the ledger browser functionality:
Assistance in adding tests would be greatly appreciated.
@esune @WadeBarnes I've rebased this PR, with latest dependency upgrades (incl for indy_vdr)
The reason that previously
No matching distribution found for aiohttp-jinja2~=1.5.1
, is because the base image being used in the docker file is running python 3.6.13 ... now, even 3.7 is end-of-life since mid 2023. So I included a manual installation of python 3.8 in the dockerfile. It may be worth updating the base image include a newer python version instead.Upgrading to 3.10 should probably be the way to go ... 3.11/3.12 may have some breaking changes, but I guess 3.10 would work fine and then we're good til 2026!
Due to the fact the all of von-network's containers are built off the network's node image, updating python has the potential of impacting operation of the nodes.
Ultimately I'd like to separate the images (webserver, client, and node) so they can evolve independently of each other. I'd also like to switch over to using a more pure image for the node, similar to (if not) the one in hyperledger/indy-node-container.
Going through changelogs of updated dependencies doesn't indicate any potential breaking changes, but it's hard to know if this repo has no tests.
It's primarily
rlp
which has gone from 0.6.0 to 3.0.0, which may require some refactoring. Everything else should remain the sameNote:
indy_vdr
is probably due for another release, as there are many changes on main. Last release was Jan 2022