-
Notifications
You must be signed in to change notification settings - Fork 35
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: apply .bashrc when running a task #395
Conversation
Signed-off-by: vitaliy-guliy <[email protected]>
Pull Request images published ✨ Editor: quay.io/che-incubator-pull-requests/che-code:pr-395-amd64 |
@AObuchow wdyt? |
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.
👍
@@ -136,6 +138,11 @@ export class MachineExecClient implements vscode.Disposable { | |||
* @returns a TerminalSession object to manage the created terminal session | |||
*/ | |||
async createTerminalSession(component: string, commandLine?: string, workdir?: string, columns: number = 80, rows: number = 24): Promise<TerminalSession> { | |||
if (commandLine) { | |||
const bashrc = join(env.HOME!, '.bashrc'); | |||
commandLine = `test -f ${bashrc} >> /dev/null 2>&1 && source ${bashrc};${commandLine}`; |
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.
It's worth creating a .bashrc
that will cause an error (e.g. add cat nonExistentFile.txt
) to see if that breaks running Devfile tasks with this approach. In theory, it shouldn't since we are using ;
instead of &&
. However, I suspect any errors in calling source ~/.bashrc
will be logged when running the Devfile task. I'm not sure if that is desired?
A potential advantage of #383 is that we only call source ~/.bashrc
once, and catch the error.
In the current approach, if the call to source ~/.bashrc
results in any errors, the errors will repeatedly be hit when running a devfile task.
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.
I like the idea to experiment with .bashrc
. Let me then update the repository I'm using to test the pull request.
However, I suspect any errors in calling source ~/.bashrc will be logged when running the Devfile task. I'm not sure if that is desired?
Good catch. I will experiment with this as well.
I found another mistaking.
As result |
Isin't that the intended behaviour for resolving eclipse-che/che#23009 however? I thought we wanted the same $PATH in other containers that the tooling has? |
If the container has its own |
Signed-off-by: vitaliy-guliy <[email protected]>
Signed-off-by: vitaliy-guliy <[email protected]>
Pull Request images published ✨ Editor: quay.io/che-incubator-pull-requests/che-code:pr-395-amd64 |
There is no To test the behavior I created a
and then checked for the file
After that I launched |
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 👍
Build 3.17 :: code_3.x/1450: Console, Changes, Git Data |
Build 3.16 :: code_3.16/1: Console, Changes, Git Data |
Build 3.16 :: sync-to-downstream_3.16/6: Console, Changes, Git Data |
Build 3.17 :: sync-to-downstream_3.x/7396: Console, Changes, Git Data |
Build 3.16 :: push-latest-container-to-quay_3.16/10: Console, Changes, Git Data |
Build 3.16 :: get-sources-rhpkg-container-build_3.16/6: code : 3.16 :: Build 63210162 : quay.io/devspaces/code-rhel8:3.16-16 |
Build 3.16 :: update-digests_3.16/10: Console, Changes, Git Data |
Build 3.16 :: code_3.16/1: Upstream sync done; /DS_CI/sync-to-downstream_3.16/6 triggered |
Build 3.16 :: operator-bundle_3.16/5: Console, Changes, Git Data |
Build 3.16 :: sync-to-downstream_3.16/11: Console, Changes, Git Data |
Build 3.17 :: push-latest-container-to-quay_3.x/4860: Console, Changes, Git Data |
Build 3.17 :: get-sources-rhpkg-container-build_3.x/7378: code : 3.x :: Build 63210209 : quay.io/devspaces/code-rhel8:3.17-1 |
Build 3.17 :: code_3.x/1450: Upstream sync done; /DS_CI/sync-to-downstream_3.x/7396 triggered |
Build 3.17 :: update-digests_3.x/7270: Console, Changes, Git Data |
Build 3.17 :: operator-bundle_3.x/3399: Console, Changes, Git Data |
Build 3.17 :: sync-to-downstream_3.x/7402: Console, Changes, Git Data |
Build 3.16 :: push-latest-container-to-quay_3.16/11: Console, Changes, Git Data |
Build 3.17 :: get-sources-rhpkg-container-build_3.x/7384: devspaces-operator-bundle : 3.x :: Failed in 63219318 : BREW:BUILD/STATUS:UNKNOWN |
Build 3.16 :: copyIIBsToQuay/2748: Console, Changes, Git Data |
Build 3.16 :: sync-to-downstream_3.16/11: Build container: devspaces-operator-bundle synced; /DS_CI/get-sources-rhpkg-container-build_3.16/11 triggered; /job/DS_CI/job/dsc_3.16 triggered; |
Build 3.16 :: operator-bundle_3.16/5: Upstream sync done; /DS_CI/sync-to-downstream_3.16/11 triggered |
Build 3.16 :: dsc_3.16/6: Console, Changes, Git Data |
Build 3.16 :: update-digests_3.16/10: Detected new images: rebuild operator-bundle |
Build 3.16 :: dsc_3.16/6: 3.16.0-CI |
What does this PR do?
This is alternative to #383
What issues does this PR fix?
eclipse-che/che#23009
How to test this PR?
create a workspace using following
repository https://github.com/vitaliy-guliy/vscode-test-extension/tree/test-sh-terminal
editor quay.io/che-incubator-pull-requests/che-code:pr-395-amd64
launch test tasks to check the variables for
tools
andmongo
containerscheck PATH environment variable
The variable seems to be different because of different .bashrs files in both containers.
Does this PR contain changes that override default upstream Code-OSS behavior?
git rebase
were added to the .rebase folder