Skip to content

Conversation

@trulede
Copy link
Contributor

@trulede trulede commented Sep 27, 2025

Relocate the calculation of an included tasks task.Dir until the templating is available.

Previously, task.DIr would be calculated earlier which resulted in SmartJoin() incorrectly evaluating the second parameter, which had not been expanded (i.e. {{.FOO}}. To get correct behaviour, SmartJoin() needed to be called later, during compilation of the imported task, so that the second parameter could first be expanded, and then used correctly with SmartJoin().

fixes #2443
fixes #2497
fixes #1690
fixes #951

when the task is compiled the task.Dir can be determined using
the template cache (not available when the AST is being
constructed).
@trulede trulede marked this pull request as ready for review November 9, 2025 13:37
@trulede
Copy link
Contributor Author

trulede commented Nov 9, 2025

@andreynering @vmaerten In this PR I've relocated the point where an imported task.Dir is calculated, and as a result it is possible to use template variables in the include.dir. This is certainly helpful as many users of the Import feature encouter this limitation as some point and it is confusing as to why it does not work.

However, some tests (2) are proving to be remarkably flakey. These are sometimes passing, sometimes failing.

  • TestIncludedTaskfileVarMerging/foo (taskfile)
  • TestIncludedTaskfileVarMerging/bar (taskfile)

These test cases have two imported Taskfiles, each with the same global var DIR, and each setting that var to a different value. I wonder if there is a data-race (existing or introduced).

You might have ideas why that is the case? It seems unrelated to the effects of #2350, and somehow related to this PR. In either case I would likely add some additinal testcases to cover the change in functionality added by this PR.

@andreynering
Copy link
Member

Hey @trulede!

First of all, thanks for your patience! I know if have many PRs opened and we are overdue on reviewing them.

I debugged this flaky test a little bit, but couldn't quickly find the problem, and want to focus on other PRs for today.

But to add context, this was originally fixed by @pd93 on the following PR, and your changes probably made that fix insufficient for some reason.

@trulede
Copy link
Contributor Author

trulede commented Nov 11, 2025

@andreynering OK, thanks. I will take a look.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

2 participants