dvc update should consider "cache: false" setting of output in imported `.dvc`

[aschuh-hf]

On suggestion by @shcheklein, I added cache: false to the output in the .dvc file created by dvc import to be able to track the imported file with Git instead of DVC. However, dvc update still adds the output to .gitignore. Also, when I use git add -f to track the file despite it being ignored, then dvc update will complain that the output is already tracked by the SCM.

Should dvc update take into account the cache: false flag of the output in the input .dvc file?

[shcheklein]

Yes, seems like a bug to me. It should not be changing the .gitignore in this case. @aschuh-hf do you have a simple script to reproduce this?

[aschuh-hf]

You can run the below shell script in an empty directory (it will delete an existing .gitignore file).

fail()
{
    echo "Error: $@"
    exit 1
}

# dvc import --rev 3.53.1 https://github.com/iterative/dvc.git CITATION.cff
# test -f .gitignore || fail "expected .gitignore to exist after dvc import"
# echo "  cache: false" >> CITATION.cff.dvc

cat <<EOF > CITATION.cff.dvc
md5: b0bfde40bc9970c29f3bebca182376ce
frozen: true
deps:
- path: CITATION.cff
  repo:
    url: https://github.com/iterative/dvc.git
    rev: 3.53.1
    rev_lock: 1bef0da4fbfaac1d68a856eef5065c974feb27ad
outs:
- md5: f36820b613457840804bf13b5ed098e7
  size: 784
  hash: md5
  path: CITATION.cff
  cache: false
EOF

rm -f .gitignore
dvc update CITATION.cff.dvc
! test -f .gitignore || fail "expected no .gitignore to be added by dvc update"

[shcheklein]

Thanks @aschuh-hf ! How bad / critical it is for you atm?

[aschuh-hf]

Not critical. I decided to stick with the default behavior of not tracking the imported file with Git.

Related to this, but different. I noticed that dvc push does not push the imported file from the local DVC cache to the remote storage. I thought I could do this and then just dvc pull it in a GitHub Actions workflow before running a DVC stage which depends on the imported file via dvc repro -s. In the hope that the workflow would then only need access to the remote storage, but not also to the private GitHub repository from where the file was imported.

But this didn't seem to work and either dvc repro or dvc pull (can't remember) did need access to the other private repository, which therefore requires setting up SSH deployment keys and secrets for the GitHub action.

If

dvc pull imported_file
dvc repro -s stage_using_imported_file

would not have to query the source repo, it would avoid this more complicated GitHub Actions workflow configuration.

The idea of tracking the imported file with Git is related in that I thought maybe then I can have the stage dependency already present and also avoid the access of the other private repository.