AI Workbench Projects
An AI Workbench project contains everything you need to do your work, such as code, data, models, environment configuration, metadata, and work history. AI Workbench projects are specially-formatted Git repositories, and if you add the required configuration files, any Git repository can become an AI Workbench project. When you create a project you choose a base environment for it, and AI Workbench runs the project in it’s own containerized development environment. For more information about AI Workbench, see NVIDIA AI Workbench.
You can move your projects between different computers with different compute resources. For more information, see Access a Project From Multiple Locations.
Use this documentation to learn about the following:
AI Workbench projects are specially-formatted Git repositories. When you create a new project, AI Workbench creates the following default structure. These files together represent the AI Workbench project.
To make a Git repository into an AI Workbench project, create the .project/spec.yaml file. For the full spec file reference, see AI Workbench Project Specification.
File or Folder |
Description |
Required? |
Git? |
|---|---|---|---|
| .project/configpacks | Used by AI Workbench to track when configpacks are run to prevent duplication. | Generated by AI Workbench. | Tracked by Git. |
| .project/spec.yaml | The specification file that contains the metadata that defines the project. For the full spec file reference, see AI Workbench Project Specification. | Yes | Tracked by Git. |
| code/ | The default location for your code files. | No | Tracked by Git. |
| data/ | The default location for your data files. | No | Tracked by Git LFS. |
| data/scratch | The default location for intermediate data products. | No | Ignored by Git. Files written here are not versioned or synced. |
| models/ | The default location for your models. | No | Tracked by Git LFS. |
| .gitattributes | A file that defines Git attributes for the relevant folders in the project. For more information, see AI Workbench Projects and Git. | Yes | Tracked by Git. |
| .gitignore | Use this file to control what does and does not get committed to your repository. The default file targets typical python development. For more information, see AI Workbench Projects and Git. | Yes | Tracked by Git. |
| apt.txt | Use this file to add apt packages to your project. Specify 1 package per line. For more information, see Packages. |
No | Tracked by Git. |
| postBuild.bash | A script that runs after installing packages. The script runs as the container user, and you have passwordless sudo available in the script. For more information, see Scripts. |
No | Tracked by Git. |
| preBuild.bash | A script that runs before installing packages. The script runs as the container user, and you have passwordless sudo available in the script. For more information, see Scripts. |
No | Tracked by Git. |
| README.md | The README file for your project, written in markdown. | No | Tracked by Git. |
| requirements.txt | Use this file to add pip packages to your project. Specify 1 package per line. For more information, see Packages. |
No | Tracked by Git. |
| variables.env | A file that contains non-sensitive environment variables to set in the project at runtime. These variables are not built into the container image. For more information, see Environment Variables. | No | Tracked by Git. |
We recommend that you don’t commit intermediate data, or other large files that you can easily recreate, to avoid bloating your Git repository. You can use the data/scratch directory, which is ignored by Git, to store temporary data. You can also create your own directory for this purpose and add it to the .gitignore file.
AI Workbench warns you when large files are about to be tracked by Git. You can move the files to an untracked location, to a Git LFS tracked location, or delete them altogether. Git LFS tracked locations are listed in the .gitattributes file.
For more information, see Git in AI Workbench.
When you work in a container, files written to the container’s filesystem do not persist when you restart the container. AI Workbench removes containers when they stop, which means that any changes you make to the container are lost.
To persist project data between restarts, use a mount. A mount allows you to persist data even after the container is stopped or removed. A host mount binds a directory from your host computer into the container. A volume mount creates a Docker/Podman volume to store data.
For more information, see AI Workbench Mounts.
By default, each project has a project mount for the container so that changes you make to project code itself (like postBuild.bash) persist across container restarts.
Whenever you change your project environment, you must perform a rebuild of the project container before you can access the changes.
Rebuild by using the desktop application
To rebuild your environment by using the AI Workbench desktop application, do the following.
In AI Workbench, on the Environment page, if your environment is running, click Stop Environment.
Wait until you see Build Required next to Environment.
Click Start Build.
The project builds. Wait until you see Build Ready in the status bar.
Click Start Environment.
Rebuild by using the CLI
To rebuild your environment by using the AI Workbench CLI, do the following.
Run the following command to stop your container environment. If the container is already stopped you see a message that the container is not running. Continue to the next step.
nvwb stop --container
Run the following command to rebuild your project.
nvwb build
The project builds. Wait until you see Container build complete and then go to the next section to test your new package.
Run the following command to start your container environment.
nvwb start --container