Tasks with copier update fail if they need a Git repo

[jashan-lco]

Describe the problem

I have a task that relies on the project tree being a Git repository. i.e. I'm using gh (Github CLI) to perform some automation after a template has been rendered.

Everything works fine when using copier copy, but when doing a copier update things fail. Doing a cursory check it looks like copier does not create a Git repo under /tmp/copier._main.old_copy.0si_f3td, which causes tools that expect the source tree to be such to fail.

Template

copier.yaml:

_tasks:
  - |-
        gh api --method PATCH repos/{owner}/{repo}/properties/values -f 'properties[][property_name]=something' -f 'properties[][value]=true'

To Reproduce

1. Run copier copy
2. Then run copier update

Logs

Expected behavior

Tasks should run the same, whether for copy or update

Screenshots/screencasts/logs

No response

Operating system

Linux

Operating system distribution and version

Archlinux

Copier version

9.11.0

Python version

CPython 3.13

Installation method

distro package

Additional context

No response

[sisp]

You're right, neither the temporary location of the old nor for thew copy is a Git repository before the fresh copy is performed, and I agree that it should be as you expect. I think adding

git("init", retcode=None)

above

copier/copier/_main.py

Line 1210 in cd45f37

old_worker.run_copy()

and

copier/copier/_main.py

Line 1288 in cd45f37

new_worker.run_copy()

should fix the problem.

I'm out of office this week, but if you'd like to submit a PR along with a test in tests/test_updatediff.py (e.g., update with update-only task that fails when the current working directory is not a Git repository), I'll try to review it.

[sisp]

I wonder whether we should also copy the Git config from the real repo to the temporary repos. Does the the GitHub CLI rely on some repo-local information like the remote repo URL?

By the way, I think you need to be careful when running a task that performs some kind of write operation like in your case. Copier's update algorithm executes tasks also after creating fresh copies of the old and new template versions in temporary locations. I imagine you'd want your gh api ... command to be executed only once after the update. For this, it's probably better to run it as a post-migration task rather than a regular task (which runs after any copy operation including the update algorithm's internal ones).

[jashan-lco]

I wonder whether we should also copy the Git config from the real repo to the temporary repos. Does the the GitHub CLI rely on some repo-local information like the remote repo URL?

It must, to be able to string interpolate things like repos/{owner}/{repo}/properties/values.

By the way, I think you need to be careful when running a task that performs some kind of write operation like in your case. Copier's update algorithm executes tasks also after creating fresh copies of the old and new template versions in temporary locations. I imagine you'd want your gh api ... command to be executed only once after the update. For this, it's probably better to run it as a post-migration task rather than a regular task (which runs after any copy operation including the update algorithm's internal ones).

That's good to know. Yes, I'd like to run the command only once after the update. But I'd also like to run the task after the initial copy. Is that possible with post-migration tasks?

[sisp]

That's good to know. Yes, I'd like to run the command only once after the update. But I'd also like to run the task after the initial copy. Is that possible with post-migration tasks?

I think so, for example with something like this (using YAML anchors/aliases to deduplicate the command):

For example:

_tasks:
  - command: &gh-patch |-
      gh api --method PATCH repos/{owner}/{repo}/properties/values -f 'properties[][property_name]=something' -f 'properties[][value]=true'
    when: "{{ _copier_operation == 'copy' }}"

_migrations:
  - *gh-patch

[jashan-lco]

That's good to know. Yes, I'd like to run the command only once after the update. But I'd also like to run the task after the initial copy. Is that possible with post-migration tasks?

I think so, for example with something like this (using YAML anchors/aliases to deduplicate the command):

For example:

_tasks:

• command: &gh-patch |-
  gh api --method PATCH repos/{owner}/{repo}/properties/values -f 'properties[][property_name]=something' -f 'properties[][value]=true'
  when: "{{ _copier_operation == 'copy' }}"

_migrations:

• *gh-patch

Oh, that's awesome. Forgot YAML anchors & aliases are a thing. Thanks!