add procedure to configure non-annexing of docker metadata

[bpinsard]

resolves #197

[qlty-cloud-legacy]

Code Climate has analyzed commit c1ffe67 and detected 0 issues on this pull request.

View more on Code Climate.

[codecov]

Codecov Report

Patch coverage has no change and project coverage change: +0.07 🎉

Comparison is base (c3bb747) 93.82% compared to head (c1ffe67) 93.90%.

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #204      +/-   ##
==========================================
+ Coverage   93.82%   93.90%   +0.07%     
==========================================
  Files          19       19              
  Lines         956      968      +12     
==========================================
+ Hits          897      909      +12     
  Misses         59       59              

see 2 files with indirect coverage changes

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

☔ View full report in Codecov by Sentry.
📢 Do you have feedback about the report comment? Let us know in this issue.

[yarikoptic]

I wonder if cfg_containers wouldn't be too broad/non-specific, this specific to docker manifests right? so smth more like cfg_dockermanifests2git (I know - mouth full).

But then I wonder why I didn't ask why you just don't use generic cfg_text2git? may be that would obliterate the need for the PR as well?

and as with anything else we would need some basic unittest, can see e.g. https://github.com/datalad/datalad/blob/HEAD/datalad/local/tests/test_run_procedure.py#L350 for an example

[yarikoptic]

I will move it to Draft. I guess we should decide first on how/if to proceed with this, or just rely on cfg_text2git may be.

[adswa]

I think the issue this PR fixes is quite important to fix. Is there anything I can do to help?

[adswa]

But then I wonder why I didn't ask why you just don't use generic cfg_text2git? may be that would obliterate the need for the PR as well?

I would say that cfg_text2git goes too far. It alters much more dataset behavior than would be required to hangle containers. We quite often see cases where text2git configurations cause trouble when used without consideration for the specific usecase, recent examples were for example behavioral logfiles that were supposed to stay private (thus annexed), or a case in which gigantic textfiles were generated and placed to Git which eventually caused Git to revolt.

I wonder if cfg_containers wouldn't be too broad/non-specific, this specific to docker manifests right? so smth more like cfg_dockermanifests2git (I know - mouth full).

I agree that it would be useful to extend this configuration to also work with singularity images (which would be placed in .datalad/environments/<name>/image. I'm not too familiar with the docker setup, but if there is a glob that could match both of them, I'd be in favor. Then the name cfg_containers would also be very fitting IMHO