- Project files
- Project settings
- Export and import
- Finding projects in Domino
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.
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.
There are several special filenames reserved by Domino. These files control the revisioning behavior, results display, and run comparison features of a project.
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.
.git/directory is always ignored by Domino sync operations, even if that pattern is not listed in
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.
.dominoresults file that contains the following lines will display all PDF files in the project, plus any PNG files that are in the
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.
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 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 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.
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.
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.
There are two settings that affect who has access to a project:
- Visibility settings
- Collaborator permissions
There are three different visibility options in Domino:
Anyone with access to the deployment can view your files and runs. If file exports are enabled, anyone can import your project files. Only explicit collaborators can modify files, start runs, or import environment variables.
Anyone will be able to see this project exists, and see its name and description in search results. However, they willnot be able to open the project to view its contents, like files or runs.
Only users added as collaborators can view this project or discover its existence through search results.
The default initial visibility setting of new projects is configurable by local administrators for your deployment. You can change your project’s visibility from the Access & Sharing tab of the project settings. If your project visibility is set to Public, there is an additional option to allow runs by anonymous users. This will allow users with access to Domino to start runs even if they don’t have a Domino account. Runs started by anonymous users will display as being started by the project owner.
Allowing anyone to run your code can be dangerous. Be careful granting this level of access, and consider what information you may be revealing to users who run your code, such as project environment variables. Also consider the potential hardware costs incurred by anonymous users starting runs.
To grant other Domino users access to your project, go to the Access & Sharing tab of the project settings. You can add new collaborators by their username or email address, and you can add permissions for all members of organizations. The owner of a project can set different access levels for collaborators.
|Read project contents||X||X||X|
|Write project contents||X||X|
|Access published apps||X||X||X|
|Change project name||X|
|Change hardware tier||X|
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.
The path of your project will also change from
/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
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.
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.
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 Importer, Contributor, 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.
Whenever you log in to Domino, you will be directed to the Projects page. Here you can find projects you own, and projects you have been invited to collaborate on by your colleagues or organization. From this interface you can also create projects, manage project tags, and assess project health and status.
There are three views available on this page: List View, Card View, and Graph View. By default, this page will show Card View.
You can quickly see basic information about a project from its card:
From top to bottom, the card displays:
- Project path, in the form of
- Project description
- A three-column status bar showing:
- Active runs and total running time
- Success or failure of recent runs
- Project hardware settings
- The most recent results from the project, with an arrow linking to the results details
- Available Launchers if any have been created in the project
List View shows only active runs, success or failure of recents runs, and the most recent results. It is possible to view more projects at once with List View:
Graph View shows a connected graph representing project dependencies. In this view, a project that imports content from another project will be shown as a child of the exporting project. The image below shows the
quick-start project importing content from
data-quick-start. You can click on any node in the graph to open the represented project. Note that this graph will include all projects you have access to, and may grow very large if your deployment has many public projects.