fix(cli): allow push to a Studio Web function project - #1870
Merged
Conversation
Function projects are created in Studio Web without a pyproject.toml because they may hold Python or TypeScript/JavaScript sources, so the coded-project check rejected the first push with "not of type coded agent" once the scaffolded files were present. Fall back to the project type when the configuration file is missing: a Function project is accepted unless it already holds a package.json, while every other project type still requires pyproject.toml.
github-actions
Bot
added
test:uipath-langchain
Contributor
There was a problem hiding this comment.
Pull request overview
This PR updates the UiPath Python CLI’s Studio Web project validation so that pushes/pulls to Function projects (which may start without a pyproject.toml) are allowed by falling back to the remote project type, while still rejecting incompatible projects and TypeScript/JavaScript Function projects.
Changes:
- Replace the “must have
pyproject.toml” gate with a fallback toGET /studio_/backend/api/Project/{id}when the config is missing, allowingprojectType == "Function"unlesspackage.jsonexists. - Cache project details in
StudioClientand reuse them for_get_solution_id. - Add unit tests covering scaffolded Function projects (allowed) and TypeScript Function projects (rejected), and update existing negative tests to mock the new project-details call.
Reviewed changes
Copilot reviewed 9 out of 11 changed files in this pull request and generated 1 comment.
Show a summary per file
| File | Description |
|---|---|
| packages/uipath/src/uipath/_cli/_utils/_studio_project.py | Adds project-details caching and updates coded-project validation to allow Studio Web Function projects while rejecting Node-based ones. |
| packages/uipath/src/uipath/_cli/_utils/_common.py | Renames validation entrypoint to ensure_coded_project and adds a dedicated error message for non-Python Function projects. |
| packages/uipath/src/uipath/_cli/cli_push.py | Switches push command to call ensure_coded_project. |
| packages/uipath/src/uipath/_cli/cli_pull.py | Switches pull command to call ensure_coded_project. |
| packages/uipath/tests/cli/test_push.py | Adds tests for pushing to scaffolded Function projects and rejecting TypeScript Function projects; updates mocks for project details. |
| packages/uipath/tests/cli/test_pull.py | Updates mocks for project details in non-coded project validation tests. |
| packages/uipath-platform/src/uipath/platform/constants/init.py | Introduces NODE_CONFIGURATION_FILE = "package.json" constant used by the CLI gate. |
| packages/uipath/pyproject.toml | Bumps uipath version and updates dependency on uipath-platform to >=0.2.21. |
| packages/uipath-platform/pyproject.toml | Bumps uipath-platform version. |
| packages/uipath/uv.lock | Updates locked editable package version metadata (uipath and uipath-platform). |
| packages/uipath-platform/uv.lock | Updates locked editable package version metadata (uipath-platform). |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
Comment on lines
+535
to
+536
| async def get_project_type_async(self) -> Optional[str]: | ||
| return (await self._get_project_details()).get("projectType") |
|
CatalinB7
approved these changes
Aug 26, 2026
andreibalas-uipath
added a commit
that referenced
this pull request
Aug 26, 2026
uipath new wrote a hard-coded "uipath>=2.10.0, <2.11.0" range, so uv sync downgraded freshly scaffolded projects to 2.10.x on machines running 2.14.x. The pin is now built from the installed distribution's major.minor via _get_safe_version() (same >=X.Y.0, <X.(Y+1).0 shape). When metadata is unavailable it falls back to a range generated from FALLBACK_UIPATH_MINOR, with a warning; a test asserts the fallback admits the installed release so the literal cannot rot silently again. Also: write a GUID id into the scaffolded uipath.json (mirrors init's backfill, silences the 'id' field not present warning), declare packaging as a dev dependency, and fix the impossible uipath-langchain>=2.0 pin in docs/core/agents.md. Bumps uipath to 2.14.9 per repo convention (2.14.8 was taken by #1870). Refs UV-16117 Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
andreibalas-uipath
added a commit
that referenced
this pull request
Aug 26, 2026
uipath new wrote a hard-coded "uipath>=2.10.0, <2.11.0" range, so uv sync downgraded freshly scaffolded projects to 2.10.x on machines running 2.14.x. The pin is now built from the installed distribution's major.minor via _get_safe_version() (same >=X.Y.0, <X.(Y+1).0 shape). When metadata is unavailable it falls back to a range generated from FALLBACK_UIPATH_MINOR, with a warning; a test asserts the fallback admits the installed release so the literal cannot rot silently again. Also: write a GUID id into the scaffolded uipath.json (mirrors init's backfill, silences the 'id' field not present warning), declare packaging as a dev dependency, and fix the impossible uipath-langchain>=2.0 pin in docs/core/agents.md. Bumps uipath to 2.14.9 per repo convention (2.14.8 was taken by #1870). Refs UV-16117 Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
Creating a project of type Function in Studio Web and pushing it with the project key from the UI fails:
ensure_coded_agent_project_asyncdecided whether a remote project accepts a Python push by looking forpyproject.tomlin the remote root. A freshly created Function project has no configuration file (it may hold Python or TypeScript/JavaScript sources, so Studio Web cannot pick one), but it is not empty either: it shipsproject.uiprojand.project/JitCustomTypes.json. The structure is non-empty and has nopyproject.toml, so the check rejected the very first push.Change
The check now falls back to the project type reported by
GET /studio_/backend/api/Project/{id}when the configuration file is missing:pyproject.tomlpresent, or the remote is empty: allowed, as before.projectType == "Function": allowed, unless the remote already holds apackage.json(a TypeScript/JavaScript function), which gets its own message.pyproject.toml, so a low-code agent project is still rejected.The project details call is lazy (only made when
pyproject.tomlis absent) and cached, and it now also backs_get_solution_id, which was making the same request.ensure_coded_agent_projectis renamed toensure_coded_projectsince it no longer covers agents only.