Skip to content
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

deploy_path cannot be relative for all tasks and recipes #3701

Open
SimJoSt opened this issue Sep 22, 2023 · 3 comments
Open

deploy_path cannot be relative for all tasks and recipes #3701

SimJoSt opened this issue Sep 22, 2023 · 3 comments

Comments

@SimJoSt
Copy link
Contributor

SimJoSt commented Sep 22, 2023

For example, half of the deploy:release recipe can work with a relative path, but some commands require it to be absolute.
It would be great to have everything support relative paths.
Alternatively, it should be clear that alternative paths are not supported.

@antonmedv
Copy link
Member

What do you mean by relative deploy_path? Usally it is a good idea to specify deploy_path from / or from ~.

@boesing
Copy link

boesing commented Sep 26, 2023

Might be related to #3689 (comment)

Using relative path or ~ does not work when using become as the ~ will always reference the SSH user and not the home of the become user, at least for rsync.

@SimJoSt
Copy link
Contributor Author

SimJoSt commented Sep 28, 2023

@antonmedv you are right, there is a key piece of information that I was omitting. We built a CI pipeline based on Deployer and added a localhost('ci') host. We wanted to use a ./.deployer/build/ directory in the project root, to perform all the build tasks in.
As the system or paths might change in which we would run the build commands, we hoped we could just use ./deployer/build as our deploy_path and it would interpret this as relative to the project root for the localhost host.

For remote hosts, we do use absolute paths for the deploy_path.
However, relative paths to the user's home directory, would make sense too. We haven't tested using the ~/ syntax yet, which could be an option. Thank you for pointing that out @boesing. As we don't use become for now, it might work for us.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants