-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix: add path to WorkingDir methods #2180
fix: add path to WorkingDir methods #2180
Conversation
`WorkingDirLocker` and `WorkingDir` are closely related -- the former acquires a lock, which ensures that the latter can safely operate on a given file path. In runatlantis#2131 we added `path` to the `WorkingDirLocker` lock key, but neglected to add the same to `WorkingDir`. This commit adds `path` as an argument to certain `WorkingDir` methods, and includes `path` in the directory that we use to clone the repository for a given project. Since `path` can include certain special characters such as `/`, we encode `path` as base32 when using it as part of a file path. This should ensure no special characters are used in the filesystem, and that the value can be decoded if desired (unlike hashes such as md5). Additional changes: - All calls to changed methods have been updated, including unit tests - Mocks have been regenerated for `WorkingDir` and `WorkingDirLocker` - `working_dir_test.go` - Commands that operate on filesystem paths have been updated to include the base32 encoded `path` value - When running `git init`, we include `-b master` as additional arguments, to ensure that `master` is our default branch (expected by the unit tests)
In addition to iterating over `workspaceDirs`, also iterate over `pathDirs`, and use both `workspace` and `path` to build `repoDir`.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
thanks for the contribution @KevinSnyderCodes |
Please give it a try in the prerelease |
might be unrelated but I started to get following with the latest dev image
I'll try using absolute paths for |
latest prerelease image?
…On Tue., Apr. 12, 2022, 5:15 a.m. Ed Laur, ***@***.***> wrote:
might be unrelated but I started to get following with the latest dev image
dir ".tmp/prod-production/my-service/infra" does not exist
—
Reply to this email directly, view it on GitHub
<#2180 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAQ3ERACYZVM3HGASQHAFPTVEVSNTANCNFSM5SQZR24A>
.
You are receiving this because you modified the open/close state.Message
ID: ***@***.***>
|
@jamengual I did use |
mmm I think dev and prerelease are the same, we should delete the dev tag but just in case this is the one: docker pull ghcr.io/runatlantis/atlantis:v0.19.3-pre.20220408 |
@edbighead please report back your findings |
sure, I will. gonna check the 0.19.2 and prerelease versions. We use |
@jamengual @KevinSnyderCodes I do get the below mentioned error on It happens in the repo with repos:
- id: github.com/org/repo
apply_requirements: ["approved"]
allowed_overrides: [workflow]
allow_custom_workflows: true
pre_workflow_hooks:
- run: render --path . --output . where atlantis.yaml version: 3
projects:
- dir: .tmp/prod-production/my-service/infra
name: prod-production-my-service-infra
autoplan:
when_modified: ["../../../../apps/my-service/app.tf"]
enabled: true Error:
|
This reverts commit 1a83444.
reverted due to : #2239 |
* fix: add path to WorkingDir methods `WorkingDirLocker` and `WorkingDir` are closely related -- the former acquires a lock, which ensures that the latter can safely operate on a given file path. In runatlantis#2131 we added `path` to the `WorkingDirLocker` lock key, but neglected to add the same to `WorkingDir`. This commit adds `path` as an argument to certain `WorkingDir` methods, and includes `path` in the directory that we use to clone the repository for a given project. Since `path` can include certain special characters such as `/`, we encode `path` as base32 when using it as part of a file path. This should ensure no special characters are used in the filesystem, and that the value can be decoded if desired (unlike hashes such as md5). Additional changes: - All calls to changed methods have been updated, including unit tests - Mocks have been regenerated for `WorkingDir` and `WorkingDirLocker` - `working_dir_test.go` - Commands that operate on filesystem paths have been updated to include the base32 encoded `path` value - When running `git init`, we include `-b master` as additional arguments, to ensure that `master` is our default branch (expected by the unit tests) * Try fixing E2E tests * Fix DefaultPendingPlanFinder In addition to iterating over `workspaceDirs`, also iterate over `pathDirs`, and use both `workspace` and `path` to build `repoDir`. * Fix DefaultPendingPlanFinder unit tests * Fix DefaultProjectCommandBuilder unit tests Co-authored-by: Kevin Snyder <kevinsnyder@KevinSnydersMBP.lan> Co-authored-by: Kevin Snyder <kevinsnyder@ip-192-168-1-188.ec2.internal>
…tlantis#2253) This reverts commit 1a83444.
WorkingDirLocker
andWorkingDir
are closely related -- the former acquires a lock, which ensures that the latter can safely operate on a given file path.In #2131 we added
path
to theWorkingDirLocker
lock key, but neglected to add the same toWorkingDir
.path
is the directory for an Atlantis project, relative to the root of the repository.This commit adds
path
as an argument to certainWorkingDir
methods, and includespath
in the file path that we use to clone the repository for a given Atlantis project.Since
path
can include certain special characters such as/
, we encodepath
as base32 when using it as part of a file path. This should ensure that no special characters are used in the filesystem, and that the value can be decoded if desired (unlike hashes such as md5).Additional changes:
WorkingDir
andWorkingDirLocker
working_dir_test.go
path
valuegit init
, we include-b master
as additional arguments, to ensure thatmaster
is our default branch (expected by the unit tests)