-
Notifications
You must be signed in to change notification settings - Fork 986
Implement julep run execution #1395
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
PR Reviewer Guide 🔍Here are some key observations to aid the review process:
|
PR Code Suggestions ✨Explore these optional code suggestions:
|
|||||||||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Important
Looks good to me! 👍
Reviewed everything up to f42e56f in 1 minute and 32 seconds. Click for details.
- Reviewed
102lines of code in4files - Skipped
0files when reviewing. - Skipped posting
3draft comments. View those below. - Modify your settings and rules to customize what types of comments Ellipsis leaves. And don't forget to react with 👍 or 👎 to teach Ellipsis.
1. cli/src/julep_cli/run.py:18
- Draft comment:
The task parameter is typed as UUID, which forces valid UUIDs. The docs use non-UUID examples (e.g. 'bad-id'). Consider switching to string type or updating docs for consistency. - Reason this comment was not posted:
Comment was not on a location in the diff, so it can't be submitted as a review comment.
2. cli/README.md:969
- Draft comment:
The error handling example uses '--task invalid-id'; ensure this example aligns with the UUID requirement if not updated. - Reason this comment was not posted:
Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 0% vs. threshold = 50% The example is meant to demonstrate error handling behavior when a task is not found. Using "invalid-id" clearly communicates this purpose to readers. There's no evidence in the documentation that task IDs must be UUIDs - in fact, the docs show that tasks can be referenced by "id or name" (line 952). The current example is more readable and serves its educational purpose well. The comment assumes task IDs must be UUIDs without evidence. The documentation actually contradicts this by stating tasks can be referenced by name. The current example using "invalid-id" is more readable and aligns with the documented behavior that tasks can be referenced by name or ID. Delete the comment. The current example is clear and correct according to the documentation, and changing it to a UUID would make it less readable without adding value.
3. documentation/julepcli/commands.mdx:257
- Draft comment:
The example uses '--task bad-id', which may conflict with the UUID requirement. Please update for consistency with the run command implementation. - Reason this comment was not posted:
Comment looked like it was already resolved.
Workflow ID: wflow_7pgGoR0F8pp5aCoe
You can customize by changing your verbosity settings, reacting with 👍 or 👎, replying to comments, or adding code review rules.
Signed-off-by: Diwank Singh Tomer <[email protected]>
Signed-off-by: Diwank Singh Tomer <[email protected]>
Signed-off-by: Diwank Singh Tomer <[email protected]>
|
| GitGuardian id | GitGuardian status | Secret | Commit | Filename | |
|---|---|---|---|---|---|
| 17693055 | Triggered | JSON Web Token | dbbd659 | cli/tests/test_auth.py | View secret |
🛠 Guidelines to remediate hardcoded secrets
- Understand the implications of revoking this secret by investigating where it is used in your code.
- Replace and store your secret safely. Learn here the best practices.
- Revoke and rotate this secret.
- If possible, rewrite git history. Rewriting git history is not a trivial act. You might completely break other contributing developers' workflow and you risk accidentally deleting legitimate data.
To avoid such incidents in the future consider
- following these best practices for managing and storing secrets including API keys and other credentials
- install secret detection on pre-commit to catch secret before it leaves your machine and ease remediation.
🦉 GitGuardian detects secrets in your source code to help developers and security teams secure the modern development process. You are seeing this because you or someone else with access to this repository has authorized GitGuardian to scan your pull request.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Important
Looks good to me! 👍
Reviewed 8e66a8f in 1 minute and 39 seconds. Click for details.
- Reviewed
146lines of code in1files - Skipped
0files when reviewing. - Skipped posting
4draft comments. View those below. - Modify your settings and rules to customize what types of comments Ellipsis leaves. And don't forget to react with 👍 or 👎 to teach Ellipsis.
1. .github/workflows/publish-cli-prerelease.yml:42
- Draft comment:
The grep/sed command for version extraction may not handle leading whitespace or format variations. Consider using a more robust regex. - Reason this comment was not posted:
Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 20% vs. threshold = 50% The current regex could fail if the pyproject.toml has extra whitespace. However, pyproject.toml files are typically machine-generated or follow strict formatting. The current regex works for the standard case. The suggestion is technically more robust but may be overengineering for this use case. The current version works and is simpler to read. The comment identifies a real edge case that could cause issues. If the pyproject.toml is hand-edited or formatted differently, the current regex could fail. While technically correct, this feels like premature optimization. The standard pyproject.toml format is very consistent, and the current regex handles the common case well. The comment should be removed. While technically valid, it suggests a more complex solution for an edge case that's unlikely to occur in practice, given the standardized nature of pyproject.toml files.
2. .github/workflows/publish-cli-prerelease.yml:97
- Draft comment:
With the working directory set to './cli', 'packages-dir: cli/dist/' likely resolves to './cli/cli/dist'. Use 'dist/' instead. - Reason this comment was not posted:
Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% The working directory is indeed set to ./cli for all run steps. The build step would create the dist directory inside ./cli. The PyPI publish action likely resolves paths relative to the repository root, not the working directory setting. Need to consider if the current path cli/dist/ is actually correct from the root. I could be wrong about how the PyPI publish action resolves paths - it might actually inherit the working-directory setting. The documentation for the action should be checked. Even with some uncertainty about path resolution, the current path cli/dist/ is logically correct when viewed from the repository root, which is typically how GitHub Actions work. The comment appears to be incorrect. The current path cli/dist/ is correct as it points to the dist directory inside the cli folder from the repository root.
3. .github/workflows/publish-cli-prerelease.yml:84
- Draft comment:
Ensure that the pip version in the environment supports 'pip index versions'. You might need to upgrade pip for compatibility. - Reason this comment was not posted:
Confidence changes required:33%<= threshold50%None
4. .github/workflows/publish-cli-prerelease.yml:139
- Draft comment:
Add a trailing newline at the end of the file for POSIX compliance. - Reason this comment was not posted:
Confidence changes required:33%<= threshold50%None
Workflow ID: wflow_uRg7wCcn0P4HxjOb
You can customize by changing your verbosity settings, reacting with 👍 or 👎, replying to comments, or adding code review rules.
| raise typer.Exit(1) | ||
| # AIDEV-NOTE: Execute task via Julep API and surface errors clearly | ||
| with Progress( | ||
| SpinnerColumn(), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Suggestion: Complete progress indicator
| SpinnerColumn(), | |
| execution = create_execution(client, str(task), task_input) | |
| progress.update(run_task, completed=True) |
…in permissions Co-authored-by: Copilot Autofix powered by AI <62310815+github-advanced-security[bot]@users.noreply.github.com>
User description
Summary
julep runCHANGELOG.mdTesting
poe format(fails: command not found)poe lint(fails: command not found)poe typecheck(fails: command not found)poe test(fails: command not found)poe check(fails: command not found)PR Type
Enhancement, Documentation
Description
Implemented task execution logic in
julep runwith progress feedback.Updated CLI and Markdown documentation with error handling examples.
Recorded the new feature and documentation updates in the changelog.
Changes walkthrough 📝
run.py
Implement execution logic and progress feedback in `julep run`cli/src/julep_cli/run.py
README.md
Add error handling example to CLI documentationcli/README.md
julep run.commands.mdx
Document error handling for invalid task executiondocumentation/julepcli/commands.mdx
julep run.CHANGELOG.md
Record execution logic and docs update in changelogCHANGELOG.md
julep run.Important
Implement task execution in
julep run, update documentation, and add GitHub workflow for CLI prereleases.julep runinrun.pywith progress feedback and error handling.julep.NotFoundError.poe_tasks.tomlto usepytestfor testing.README.mdandcommands.mdxwith error handling examples.CHANGELOG.mdfor new execution logic and documentation updates.publish-cli-prerelease.ymlGitHub workflow to publish CLI prereleases to PyPI fordevandmainbranches.This description was created by
for 8e66a8f. You can customize this summary. It will automatically update as commits are pushed.