Work in Domino happens in projects. Projects contain data, code, and environment settings. The entire project is tracked and revisioned automatically. A new commit is written to a project each time its files are changed by user action, or by the execution of code in the project. Users in Domino can create their own projects, invite other users to collaborate with them, and export data or results for consumption by other projects.
Domino manages a collection of files for every project. You can add files to a project in the following ways:
-
Upload them from the Domino web application.
-
Upload them from the Domino Command Line Interface.
-
Upload them through the Domino API.
-
Create and edit them in the Domino web application.
-
Execute code in a workspace or run to generate them.
When you modify a project’s files, it creates a new revision of the project. When you start a Run from a Domino project, the files in that project are loaded onto the machine hosting the Run. This machine is known as the executor.
See Domino File System to learn how Domino loads files into runs and how runs change files.
You can also add external Git repositories to projects. This makes the contents of those repositories available in runs and workspaces in the /repos directory of the executor. See Git repositories in Domino.
Special files
There are several special files reserved by Domino. These files control the revisioning behavior, results display, and run comparison features of a project.
README files
All Domino projects are initialized with a README file, which is available in the Overview section of your project. README files provide an overview of a project. The contents of the README file in your project are written in Markdown, a lightweight and easy-to-read/write markup language.
.dominoignore
By default, all projects include a .dominoignore file in the project root folder. This file functions like a .gitignore file, and can be used to exclude certain file patterns from being written to future revisions of the project files. Domino ignores files that match the specified
patterns when a new revision is created. This includes revisions created by syncing from your local machine using the CLI, as well as new revisions created by a run or workspace session.
To ignore a file pattern, add it to .dominoignore. Patterns can be filenames, folder names, or UNIX shell regular expressions. Adding a folder will ignore it along with all of its contents. The * symbol in UNIX shell regular expressions is a wildcard and will match. All paths must be relative to the project root. Review the contents of the default .dominoignore in one of your projects to see commented examples of excluded patterns.
.dominoresults
Domino projects include a special file named .dominoresults. This file controls which files≈the results dashboard lists for this project’s runs. It is constructed similar to .dominoignore, but lists file patterns to include instead of exclude. If no patterns are listed in this file, all files changed by a run will be included in the results dashboard. If any patterns are listed in this file, only files which match those patterns will be included in the results dashboard for this project’s runs.
For example, a .dominoresults file that contains the following lines will only list the following specified files in the results dashboard.
histogram.pdf
output.txtA .dominoresults file that contains the following lines lists all PDF files in the project, and any PNG files that are in the results/ folder.
*.pdf
results/*.pngdominostats.json
Domino’s run comparison feature checks for a file named dominostats.json to compare key measurables from individual runs. This file is automatically deleted at the beginning of
a run, and will only exist in the project revision produced by a run if a new version is written during execution. See runs to learn more about this feature.
There are several important settings attached to every Domino project. To access project settings, open a project overview and click Settings from the navigation pane.
Hardware tier
Hardware tiers describe the compute hardware that will be used for project executors. Executors can either be virtual instances from a cloud services provider, or a machine running in your deployment’s on-premise data center. Local administrators will configure the hardware tiers available for your deployment. Use the Hardware & Environment tab of the project settings to set a specific hardware tier for your project.
Select a hardware tier that will provide the performance your workflow needs, bearing in mind the cost of the hardware in cloud deployments, and the impact of your tenancy on local hardware in on-premise deployments. Domino will use this hardware tier for all runs started in the project. When the hardware tier is changed, it will be the default for future runs in the project, although the default can be overridden when starting a run that requires alternate hardware.
Workspace and jobs volume size
Volumes represent the storage space dedicated to your workspace or Job.
The default volume size for all workspaces and jobs in Domino is 10GiB, configurable by an administrator.
You can change the size of your volume if you find that your workspace (or Job) will require more storage space.
-
Go to your project’s settings.
-
Under "Workspace and Jobs Volume Size", enter your desired volume size. The default minimum volume size is 4GiB, while the default maximum volume size is 200GiB. Both of these values are configurable. If you’d like to change the default minimum and maximum volume size limits, contact your Domino administrator.
Compute environment
Compute environments are specifications for containers in which Domino projects run. You can create new environments and access public environments shared in your deployment or organization. Whenever a new executor is launched or provisioned for use with a project, Domino loads the compute environment specified in the Hardware & Environment tab of the project settings:
Learn more about how environments work.
Environment variables
Domino pulls environment variables from three sources whenever it loads a run or workspace:
-
User, project, and hardware information. These are stored in variables set by Domino automatically.
-
Environment variables defined in the user profile of the user starting a run.
-
Environment variables defined in the Hardware & Environment tab of the project settings.
You can use these environment variables to securely store keys and credentials needed by the project. The names of these variables must start with a letter, and contain only alphanumeric characters and underscores.
Access and sharing
See Sharing and collaboration for details about how to grant various types of access to your projects.
In Domino 3.5+, projects can be labeled with configurable stages that track their progress through a data science life cycle. If your Domino administrator has configured project stages, you will see the current stage of your project in brackets under the project name in the project menu. If you click the project name, you can use the menu that is shown to change the project stage if you are an owner or contributor on the project.
Track your project through the stages used by your team helps your colleagues understand what kind of work is happening in the project and how they can contribute. If you change the stage of a project, this event is listed in the project’s activity feed.
Projects also have a status, which is indicated by the colored pipe next to the project name.
A project’s status can be:
-
Green
Indicates an active and progressing project.
-
Red
Indicates an active project that is blocked.
-
Grey
Indicates a completed project.
By default, new projects are set to a green, active status. To modify a project’s status, click the project name at the top of the project menu to access options to mark a project as blocked or complete. When you do so, you can enter a message to describe the blocker or end result of the project. When you change the status of a project, this event is listed in the project’s activity feed with an attached comment thread, so project collaborators can discuss blockers or project conclusions.
Mark a project blocked
Project owners and contributors can mark a project as blocked. Mark a project as blocked when you need assistance from colleagues or administrators to make progress. Domino administrators and your project collaborators will receive an email notification when you mark a project as blocked. Some common cases where raising a blocker can help are:
-
You need assistance setting up additional tools in a Domino environment.
-
You need access to new data sources.
-
You need hardware capabilities not covered by your current hardware tier.
The same menu used to mark a project as blocked can be used to unblock the project, which returns it to a green, active status.
Mark a project complete
Project owners and contributors can mark a project as complete. You can record final conclusions and products in the project’s activity feed, and the project is filtered out of active project views. On your projects overview, select the Show completed projects checkbox to find projects that have been marked as complete.
The same menu used to mark a project as complete can be used to reopen the project, which returns it to a green, active status. A project marked as complete is still a fully functional Domino project. You can modify its files and start Runs in it, but before doing so you might want to reopen the project to indicate that work is continuing.
Click Activity in the project menu to open the project’s Activity Feed. This page shows the history of activity in the project, including:
-
Jobs started
-
Workspaces started
-
Comments left on Jobs or Workspaces
-
Comments left on files
-
Project stage changes
-
Blockers raised or resolved
-
Files created, edited, or deleted in the Domino UI
-
Files modified in Workspace sessions
-
Models or Apps published
-
Scheduled Jobs published or edited
You can use the menu to filter comments, Jobs, or Workspaces. If you select two successfully completed Runs in the feed, you can use the comparison button next to the filter menu to open a Run comparison.
You can to import content from one Domino project into another. The importing project may have access to the exporting project’s files, environment variables, or both, depending on configuration. During runs
with imported files, each project directory is located at /mnt/<username>/<project name>. When a run or workspace is started, these files are pulled in alongside the current project’s files.
Imported directories are read-only.
Set up export
From the project overview page, in the navigation pane, go to Settings > Exports. From this interface you can enable exports for the project’s files and environment variables separately, or export the project files as a Python or R package. If none of these are enabled, other projects cannot import anything from this project.
By default, projects will make their latest revision available for export when configured. You can also make revisions produced by specific runs available for import by tagging those runs with release. From the Runs page of a project, select the checkbox for the Runs that you want to export, then click Tag. Enter the exact string release to mark the revision created by the selected runs as available for export.
Set up import
From the Files page of the project you want to import into, click the Other Projects tab. Enter the path to the project you want to import, with the format <username>/<project-name>. The following conditions must be true for you to import a project:
-
You must have Project Importer, Contributor, or Owner permissions on the project.
-
The project must be configured for export.
After adding a project that exports files, use the Release menu to select the revision of the project files you want to import.