You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Using DVC in CI essentially requires the use of cml ci before you can use any DVC commands. Currently CML and DVC installation are separated into the iterative/setup-cml and iterative/setup-dvc actions, but there's really no way for a user to actually do anything with DVC without the use of both actions together in their workflow (meaning for all practical scenarios setup-dvc depends on setup-cml).
I was looking into making the setup-dvc action just install CML and run cml ci, but this will require adding cml_version, cml_sudo, cml_force inputs to setup-dvc, all of which may conflict with whatever the user set if they also use setup-cml in their workflow. I also considered making setup-dvc a composite action that uses: iterative/setup-cml, but this again has the same problem where the user may want a specific version of CML that ends up being stomped by the setup-dvc installation instead.
Rather than require the current state of
- uses: iterative/setup-cml
- uses: iterative/setup-dvc
- run: |
cml ci
# rest of my workflow
it seems to me that we should really have a single action (setup-cml) that has an optional dvc: or dvc_version: input that defaults to false-y (meaning DVC is not installed and cml ci is not run by default). If the option is set to latest or any other valid DVC version, DVC will be installed and cml ci would be run by default as a part of the setup-cml action.
This is semi related, but I also think cml ci (with no additional arguments) should always be run by default in iterative/setup-cml (regardless of whether or not they are using the proposed dvc_version: input). This would also cover the scenarios where the user installs DVC themselves (either because they need a pip installation to use the python api or because they are using one of the CML runner images that already includes DVC)
The text was updated successfully, but these errors were encountered:
Using DVC in CI essentially requires the use of
cml ci
before you can use any DVC commands. Currently CML and DVC installation are separated into theiterative/setup-cml
anditerative/setup-dvc
actions, but there's really no way for a user to actually do anything with DVC without the use of both actions together in their workflow (meaning for all practical scenariossetup-dvc
depends onsetup-cml
).I was looking into making the
setup-dvc
action just install CML and runcml ci
, but this will require addingcml_version
,cml_sudo
,cml_force
inputs tosetup-dvc
, all of which may conflict with whatever the user set if they also usesetup-cml
in their workflow. I also considered makingsetup-dvc
a composite action thatuses: iterative/setup-cml
, but this again has the same problem where the user may want a specific version of CML that ends up being stomped by thesetup-dvc
installation instead.Rather than require the current state of
it seems to me that we should really have a single action (
setup-cml
) that has an optionaldvc:
ordvc_version:
input that defaults to false-y (meaning DVC is not installed andcml ci
is not run by default). If the option is set tolatest
or any other valid DVC version, DVC will be installed andcml ci
would be run by default as a part of thesetup-cml
action.related: iterative/dvc#9612
This is semi related, but I also think
cml ci
(with no additional arguments) should always be run by default initerative/setup-cml
(regardless of whether or not they are using the proposeddvc_version:
input). This would also cover the scenarios where the user installs DVC themselves (either because they need a pip installation to use the python api or because they are using one of the CML runner images that already includes DVC)The text was updated successfully, but these errors were encountered: