Projects overview

Contents

Overview

Work in Domino happens in projects. Projects contain data, code, and environment settings, and 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 new projects, invite other users to collaborate on them, and export data or results for consumption by other projects.

Project files

Domino manages a collection of files for every project. Files can be added to a project in the following ways:

  • uploaded from the Domino web application
  • uploaded from the Domino Command Line Interface
  • uploaded via the Domino API
  • created and edited in the Domino web application
  • generated by the execution of code in a workspace or run

Each of these ways of modifying a project’s files creates a new revision of the project. Whenever you start a run or workspace from a Domino project, the files in that project are loaded onto the machine performing the run or hosting the workspace. This machine is known as the executor. The project files are mounted in the /mnt directory, which is in the filesystem root of the executor. Domino keeps track of changes to this directory. When a run completes or you sync your workspace, Domino will record changes to /mnt as a new revision of the project.

It is also possible to add external Git repositories to projects. Doing so makes the contents of those repositories available in runs and workspaces in the /repos directory of the executor. Click to read more about Git repositories in Domino.

Special files

There are several special filenames reserved by Domino. These files control the revisioning behavior, results display, and run comparison features of a project.

.dominoignore

By default, all projects include a .dominoignore file in the project root folder. This file functions similarly to a .gitignore file, and can be used to exclude certain file patterns from being written to future revisions of the project files. Domino will ignore files that match the specified patterns whenever 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. Note that the * symbol in UNIX shell regular expressions is a wildcard, and will match. All paths must be relative to the project root. Take a look at the contents of the default .dominoignore in one of your projects to see commented examples of excluded patterns.

Note

.git/ directory is always ignored by Domino sync operations, even if that pattern is not listed in .dominoignore.

.dominoresults

Domino projects include a special file named .dominoresults. This file controls which files appear in the results dashboard for this project’s runs. It is constructed similarly 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 display the two specified files in the results dashboard.

histogram.pdf
output.txt

.dominoresults file that contains the following lines will display all PDF files in the project, plus any PNG files that are in the results/ folder.

*.pdf
results/*.png

dominostats.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 fresh version is written during execution. Read more about runs to learn the details of how this feature works.

Project settings

There are several important settings attached to every Domino project. To access project settings, open a project overview and click Settings from the left sidebar.

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.

You should choose 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.

Compute environment

Compute environments are specifications for containers in which Domino projects will run. Users can create new environments and access public environments shared in their deployment or organization. Whenever a new executor is launched or provisioned for use with a project, Domino [or the executor if you prefer that language] loads the compute environment set in the Hardware & Environment tab of the project settings. Click to read more about how environments work.

Environment variables

Domino pulls environment variables from three sources whenever it loads a run or workspace:

  1. User, project, and hardware information. These are stored in variables set by Domino automatically.
  2. Environment variables defined in the user profile of the user starting a run.
  3. Environment variables defined in the Hardware & Environment tab of the project settings.

These environment variables can be used 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.

project-env-variables.png

Access and sharing

Read Sharing and collaboration for details on how to grant various types of access to your projects.

 

Export and Import

It is possible 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.

Note 
The path of your project will also change from /mnt to /mnt/<username>/<project name> when you have imported projects. If you have hardcoded any paths in your project code to /mnt, you should replace them with paths that use the $DOMINO_WORKING_DIR environment variable.

Setting up export

From the project overview page, in the left sidebar click Exports under Settings. 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 will not be able to import anything from this project.

export-config.png

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 runs you want to export by clicking the checkbox next to them, then click the tag button at the top of the list. Enter the exact string release to mark the revision created by the selected runs as available for export.

tag-release.png

Setting 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 successfully import a project:

  • You must have Project ImporterContributor, or Owner permissions on the project.
  • The project must be configured for export.

After adding a project that exports files, you can choose which revision of the project files you want to import with the Release menu.

 

Was this article helpful?
0 out of 0 found this helpful