fix(easy-install): various issues

[barredterra]

first issue

Resolved through #1701

second issue

Upstream frappe_docker changed the custom image Containerfile to read apps.json via a BuildKit secret. Our script still only passed the old APPS_JSON_BASE64 build arg, so the image was built with Frappe only, and --install-app erpnext failed with No module named 'erpnext'.

I updated the Docker build command to pass:

--secret id=apps_json,src=/absolute/path/to/apps.json

third issue

easy-install.py defaulted --frappe-branch to version-15, while upstream frappe_docker now builds ERPNext from version-16. That produced the Frappe/ERPNext dependency mismatch. The later pull access denied for custom-apps happened because the script swallowed the Docker build failure and continued into deploy.

Changes made:

• Default --frappe-branch is now version-16.
• Bumped default python version from 3.11 to 3.14
• Bumped default node version from 18 to 24
• Docker image build/push failures now sys.exit(1) instead of continuing.

[greptile-apps]

Confidence Score: 5/5

Changes are targeted bug fixes with no new logic paths; safe to merge.

Each change is a direct fix for a documented, reproducible failure. The BuildKit secret swap correctly mirrors the upstream Containerfile change, the fail-fast sys.exit(1) prevents silent deploy of broken images, and the SITES_RULE generation unblocks HTTPS compose. No regressions identified in the diff.

easy-install.py — specifically the build_image function around apps.json path handling.

_{Reviews (7): Last reviewed commit: "Merge remote-tracking branch 'upstream/d..." | Re-trigger Greptile}

[revant]

@Rocket-Quack @DanielRadlAMR can you confirm?

[DanielRadlAMR]

The fix for the third issue looks correct (it matches the approach in #1700, which addresses the same issue).

I left a review for the fix to the second issue. I'd recommend removing APPS_JSON_BASE64 entirely, as keeping it around defeats the purpose of switching to build secrets in the first place.

Regarding the first issue, I'd wait for @Rocket-Quack. His #1701 already tackles the same issue.

[Rocket-Quack]

Thx @DanielRadlAMR
I think it's good that some progress has been made on this fix but personally I find the implementation a bit too limited.
Especially since there is no provision for handling existing environments like used old SITES Definition.

IMHO #1701 is more suitable in this regard, but if the only way to implement the fix is through this PR then let’s go with it with the request to expand the documentation take legacy instances into account and also allow the old method of site naming.

[barredterra]

@Rocket-Quack happy to merge your PR, I'm sure it solves the problem better. I lack context and was just trying to get the CI to pass.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud