A roundup of technical Q&A's from the DVC community. This month: best practices for config files, pipeline dependency management,and caching data for CI/CD. Plus a new CML feature to launch cloud compute with Terraform!
configfile and a
config.localfile. What's best practice for committing these to my Git repository?
DVC uses the
config.local files to link your remote data
repository to your project.
config is intended to be committed to Git, while
config.local is not - it's a file that you use to store sensitive information
(e.g. your personal credentials - username, password, access keys, etc. for
remote storage) or settings that are specific to your local environment.
Usually, you don't have to worry about ensuring your
config.local file is
being ignored by Git- the only way to create a
config.local file is using the
--local flag explicitly in functions like
dvc remote and
commands, so you'll know you've made one! And your
config.local file is
.gitignored by default. If you're concerned, take a look and make sure there
are no settings in your
config.local file that you actually want in your
To learn more about
read up in our docs.
When you install DVC via
conda, it will come with dependencies like
The only exception when installing DVC as a Python library is with
might want to specify the kind of remote storage you need to make sure all
dependencies are present (like
boto for S3). You can run
pip install "dvc[<option>]", with supported options like
[ssh]. Or, use
[all] to include them all.
For more about installing DVC and its dependencies, check out our docs.
prepare.py, which imports a module
module.pychanges, how will DVC know to rerun the pipeline stage?
If your DVC pipeline only lists
prepare.py as a dependency, then changing code
in module files won't trigger a re-run of the pipeline. Meaning that if you run
dvc repro after updating
module.py, DVC will simply return the result of
your last pipeline run and a message that nothing has changed.
To explain further why this happens:
DVC is platform agnostic and it doesn't know whether your command's executable
python, some other script interpreter, or a compiled binary for that
E.g. this is a valid stage:
dvc run -o hello.txt 'echo "Hello!" > hello.txt'(where the executable is echo).
DVC also doesn't know what's going on inside the command's source code.
Therefore, any file that your code requires internally should be explicitly
specified as a pipeline stage dependency (in CLI,
dvc run -d , or in YAML,
deps:) for DVC to track it.
If you're not interested in adding modules as explicit dependencies, there are a few other approaches:
requirements.txtfile a stage dependency (if the loaded module comes from a package).
dvc repro --force <stage>.dvc) when you know an unmarked dependency is changed – although this is prone to human error.
We also have an ongoing discussion about this issue on our GitHub repository, and we'd love your input. Please participate in this issue if you can here!
dvc.yamlfile. Are there any ways to use wildcards (like
*) or specify directories as dependencies?
Yes, you can set a directory to be a dependency or an output of a DVC pipeline stage. This means you can have tens, hundreds, thousands or millions of dependency files in one directory, and all you have to declare in the pipeline is the address of that directory.
You're in luck, because we just shared this feature as part of the CML 0.3.0
pre-release! The pre-release introduced a new function,
previous method for launching instances in the cloud from a CI workflow using Docker Machine.
In the new
cml-runner function built on Terraform, you can deploy instances in
AWS and Azure with a single command (it used to take about 30 lines of code!).
For example, to launch a
t2.micro instance on AWS from your GitHub Actions or
GitLab CI workflow, you'll run:
cml-runner \ --cloud aws \ --cloud-region us-west \ --cloud-type=t2.micro \ --labels=cml-runner
[report.md](http://report.md)document that gets published to my pull request by CML. I want to save the
report.mdfile to my repository, too. Is this possible?
By default, files that are created in a GitHub Actions or GitLab CI workflow
only exist on the runner- as soon as the runner turns off, they vanish.
cml-send-comment create persistent links to
data visualizations, tables, and other outputs of your workflow so you can view
them long after your run ends. However, by design, CML doesn't commit files to
your repository (not all users want this!)
What you're likely looking for is an auto-commit, to essentially
git add and
git commit files generated by the workflow to your repository. You can
manually write this code into your workflow file, or you can use a GitHub Action
tool like the
Auto Commit or
Add & Commit Actions.
Downloading data to a runner on every CI workflow can be needlessly time consuming, particularly when the data rarely changes.
While we don't have a CML-specific mechanism in the works for this use case, there are two main approaches we see as viable: