| name | rhoai-data-science-ide-workflows |
| metadata | {"author":"rhoai3-demo","version":"1.0.0","platform-family":"rhoai","platform-baseline":"repo","ocp-baseline":"repo","skill-group":"RHOAI Platform"} |
| description | Use when documenting, reviewing, or operating Red Hat OpenShift AI data science IDE workflows from the Working in your data science IDE guide: accessing a workbench IDE; using JupyterLab to create, upload, clone, pull, push, and package notebooks; using code-server to work with notebooks, Git, Python packages, and extensions; handling user-facing Jupyter/workbench errors such as 403, startup failures, and no-space errors; and deciding when code-server is inappropriate for Elyra-based pipelines. Do NOT use for project/workbench lifecycle provisioning (use rhoai-project-workflows), custom workbench image authoring (use rhoai-workbenches-custom-images), dashboard import of workbench images (use rhoai-workbench-image-import), S3-compatible object operations from notebooks (use rhoai-s3-object-storage-data), AI Pipelines authoring (use rhoai-kfp-pipeline-authoring), or live cluster changes without the OpenShift safety guard.
|
RHOAI Data Science IDE Workflows
Use this skill for user-facing OpenShift AI IDE workflows inside running
workbenches on the active product baseline in docs/PLATFORM_BASELINE.md.
Source Grounding
Read references/source-capture.md before using product workflow details.
Official Red Hat documentation is product authority. This skill adapts the
official Working in your data science IDE guide to this repo's demo workflow
and documentation model.
Scope
This skill covers:
- accessing a running workbench IDE from the OpenShift AI dashboard
- JupyterLab notebook creation and local notebook upload
- JupyterLab Git workflows: clone, pull, commit, and push
- JupyterLab Python package inspection and
requirements.txt installation
- user-facing JupyterLab and workbench troubleshooting signals
- code-server notebook upload and Git workflows
- code-server Python package inspection and
requirements.txt installation
- code-server extension installation
- IDE support boundaries, including RStudio Server Technology Preview and
code-server lack of Elyra-based pipeline support
Use other skills for adjacent work:
rhoai-project-workflows for project and workbench creation, update,
deletion, connections, and cluster storagerhoai-connected-applications for Start basic workbench access from
Applications -> Enabled and connected application endpoint handlingrhoai-workbenches-custom-images for custom workbench image design and
image-stream-backed workbench manifestsrhoai-workbench-image-import for dashboard import of existing custom imagesrhoai-s3-object-storage-data for notebook access to S3-compatible object
storagerhoai-ai-pipelines for AI Pipelines product workflows, Elyra runtime
configuration, pipeline runs, exports, and logsrhoai-automl for saved AutoML prediction notebooks and AutoML-specific
workbench handoffrhoai-autorag for generated AutoRAG indexing and inference notebooks in a
workbenchrhoai-mlflow for MLflow SDK installation, authentication, and experiment
tracking from notebooks or podsrhoai-model-customization-training for model customization workbench setup,
Red Hat Python index package use, Docling, SDG Hub, Training Hub, and ITS
notebooksrhoai-kfp-pipeline-authoring for repo-specific KFP Python and runner coderhoai-users-groups-access for OpenShift AI user group membership issuesrhoai-basic-workbenches and env-troubleshoot for administrator-side
workbench and cluster troubleshooting
Demo Policy
For this repo:
- Use Git as the durable collaboration path for notebooks, prompts, scripts,
requirements, and examples. Treat local upload as a demo convenience, not a
source-of-truth workflow.
- Prefer
requirements.txt with exact package versions for reproducible IDE
demos. If packages are required across many workbenches, move the dependency
into a custom workbench image workflow.
- Do not commit Git credentials, tokens, storage credentials, or generated
notebook outputs that expose secrets.
- Use JupyterLab when the demo depends on notebook-native or Elyra-based
pipeline workflows.
- Use code-server when the demo benefits from a VS Code-like editor,
extensions, terminal-centric work, or multi-file application development.
- Label RStudio Server as Technology Preview and do not rely on it for
disconnected environment demos.
- User-facing troubleshooting should capture the visible symptom, then hand
off admin-side checks to
rhoai-basic-workbenches, env-troubleshoot, or
rhoai-users-groups-access as appropriate.
Workflow
- Confirm the active baseline in
docs/PLATFORM_BASELINE.md.
- Read
references/source-capture.md and
references/official-doc-extraction.md.
- Decide whether the task is:
- accessing a workbench IDE
- JupyterLab notebook, Git, package, or troubleshooting workflow
- code-server notebook, Git, package, extension, or troubleshooting workflow
- IDE support-boundary review
- Use
examples/ide-workflow-patterns.md for focused review patterns.
- For live cluster work, follow the OpenShift safety guard in
AGENTS.md.
- Validate with
references/validation-checklist.md.
References
references/source-capture.mdreferences/official-doc-extraction.mdreferences/validation-checklist.mdexamples/ide-workflow-patterns.md
