Backport of stacks: Make path.module and path.root relative, to match documentation into v1.14

[github-actions]

Backport

This PR is auto-generated from #37982 to be assessed for backporting due to the inclusion of the label 1.14-backport.

🚨

Warning automatic cherry-pick of commits failed. If the first commit failed,
you will see a blank no-op commit below. If at least one commit succeeded, you
will see the cherry-picked commits up to, not including, the commit where
the merge conflict occurred.

The person who merged in the original PR is:
@nfagerlund
This person should resolve the merge-conflict(s) by either:

• Manually completing the cherry picks into this branch
• Creating a new branch and manually cherry-picking all commits being backported

merge conflict error: POST https://api.github.com/repos/hashicorp/terraform/merges: 409 Merge conflict []

The below text is copied from the body of the original PR.

---

Previously, we were just handing off the absolute path produced by the sourcebundle struct. But that's no good, because the value doesn't stay consistent between plan and apply when running under tfc-agent. (It uses working directories named after the unique job ID.) It also doesn't match the documentation, which describes these as relative paths. This was preventing people from uploading module-provided files to create aws lambda functions, for example.

This commit addresses that by converting the source-bundle provided module path to a relative path (relative to Terraform's working directory). In tfc-agent for stacks runs, that ends up being the directory directly above the sourcebundle directory, and all the paths below that are consistent between plan and apply.

Fixes: jira IPL-8856

Target Release

Would it be okay to backport this? It's affecting customers in the wild, and there are a few other PRs in flight (@DanielMSchmidt 's) that seem patch-worthy.

1.14.2

Rollback Plan

• If a change needs to be reverted, we will roll out an update to the code within 7 days.

Changes to Security Controls

Are there any changes to security controls (access controls, encryption, logging) in this pull request? If so, explain.

No.

CHANGELOG entry

• This change is user-facing and I added a changelog entry.
  • but lemme know if I didn't do it right. It's in the 1.14 dir because I'm hoping for a backport.
• This change is not user-facing.

---

Overview of commits

• 116646a

• e19522b

[nfagerlund]

Oh funny, merge conflict on the backport. I feel like I don't see that often. lemme see.

[github-actions]

Changelog Warning

Currently this PR would target a v1.15 release. Please add a changelog entry for in the .changes/v1.15 folder, or discuss which release you'd like to target with your reviewer. If you believe this change does not need a changelog entry, please add the 'no-changelog-needed' label.

[nfagerlund]

Well, it picked cleanly so idk what that was about.

[nfagerlund]

@DanielMSchmidt I think having the changelog in the 0.14 folder should be right, still? let me know if I should change that, or add a label, or what.

[SarahFrench]

I think this is just a gap in our automation - having the change file in the v1.14 is correct when backporting a 1.14 patch release.

@nfagerlund is this ok to merge? I'm the person on release duty this week for v1.14.3 and I found this PR when checking for things to merge before Wednesday

[nfagerlund]

@SarahFrench Thanks for explaining that! Yes, in that case, this IS ok to merge. 👍🏼

[github-actions]

I'm going to lock this pull request because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active contributions.
If you have found a problem that seems related to this change, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.