-
Notifications
You must be signed in to change notification settings - Fork 13
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
Update shell rcfiles to indicate the user is already in an activated state. #2710
Conversation
cabcef3
to
dff11c9
Compare
…state. The PS1 prompt is only changed for the immediate subshell. Nested subshells do not inherit it, so it was not clear the user is still in an activated state.
dff11c9
to
3cfa3a5
Compare
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.
See comment replies
2f61415
to
1cbc286
Compare
This allows for testing bare 'bash' and 'zsh' commands. Also revert fish to zsh test change.
a1cd38c
to
43f9213
Compare
43f9213
to
71ad314
Compare
It's not clear which shell CI will pick up by default on macOS (sometimes bash, sometimes zsh), so touch to make sure.
test/integration/shell_int_test.go
Outdated
@@ -288,13 +291,19 @@ func (suite *ShellIntegrationTestSuite) TestNestedShellNotification() { | |||
|
|||
cfg, err := config.New() | |||
suite.Require().NoError(err) | |||
if runtime.GOOS == "darwin" && condition.OnCI() { | |||
cfg.Set(subshell.ConfigKeyShell, "zsh") // GitHub actions runs on bash, so override with zsh |
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'd rather we use the SHELL=zsh
environment variable, as it's more future-proof.
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.
We actually cannot do this because os.Setenv("SHELL")
will affect parallel tests. I reverted a previous change.
test/integration/shell_int_test.go
Outdated
os.Setenv(constants.HomeEnvVarName, ts.Dirs.HomeDir) | ||
defer func() { os.Unsetenv(constants.HomeEnvVarName) }() |
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.
This is not safe for other tests running in parallel. You can set it with AppendEnv though.
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've tried to minimize time spent in a modified env state. It's needed for user.HomeDir()
both in this test and spawned processes.
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.
Ok, please find an alternative to using ss.RcFile()
that doesn't require os.Setenv()
. This is just a test so it's ok if we're hard coding some stuff here so long as it's not prone to breaking all the time.
As for the process-level; AppendEnv()
should be able to handle that.
Minimizing the window doesn't change that it can impact other tests in ways that will be really hard to identify after the fact.
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've hardcoded creating and populating shellrc files like the installer would.
test/integration/shell_int_test.go
Outdated
ss := subshell.New(cfg) | ||
err = subshell.ConfigureAvailableShells(ss, cfg, nil, sscommon.InstallID, true) // mimic installer | ||
suite.Require().NoError(err) |
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.
Why is this necessary for these tests?
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.
This is needed to put the .zshrc and .bashrc script in the test userhome directory. If I don't have this, the test will fail with ".zshrc not found".
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.
Can we instead just "touch" those files? This feels like we're throwing too much at it. Especially in tests the variables should be as minimal as possible.
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've hardcoded creating and populating shellrc files like the installer would.
Using defer may interfere with parallel tests.
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.
See comment responses.
…rror message." This reverts commit 1cf9727.
test/integration/shell_int_test.go
Outdated
ss = subshell.New(cfg) | ||
} else { | ||
os.Setenv("SHELL", "zsh") // GitHub actions runs on bash, so override with zsh | ||
cfg.Set(subshell.ConfigKeyShell, "zsh") |
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.
Please get rid of the subshell package in these tests. We can just make assumptions based on OS. eg. Mac = zsh, Linux = bash, Windows = cmd.
The subshell package adds too much logic to these tests imo. I'd rather keep this dead simple and hardcoded so the tests leave little to the imagination and we don't accidentally break them without realizing it when eg. updating the subshell package.
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.
Forgive me. I was under the impression "integration tests" were meant to test as much of the existing system in-place as possible, so breaking changes introduced in the subshell packages might be caught here.
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.
Our integration tests are meant to test the built state tool. They are not meant to test the code directly, that's what unit tests are for.
Testing it like this itself can also cause issues where the test passes when in fact it shouldn't, because we are using the same code to assert as we are testing, this code would have the same bugs.
test/integration/shell_int_test.go
Outdated
suite.Require().Equal(filepath.Dir(rcFile), ts.Dirs.HomeDir, "rc file not in test suite homedir") | ||
suite.Require().FileExists(rcFile) | ||
fileutils.TouchFileUnlessExists(rcFile) | ||
sscommon.WriteRcFile(rcFileAppend, rcFile, sscommon.InstallID, nil) |
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 don't follow why we need this? The TouchFile
above seems to already be addressing the needs of this test. And without passing any env information this wouldn't actually be writing any templated data. The InstallID is also irrelevant because you're using the append template, which doesn't use this.
Pretty sure you can drop this and your test would still run as expected.
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.
If I killed line 320 as you appear to suggest, the test would fail because the shell rc file would not contain the templated if
statement that checks and prints if you are in a subshell: https://github.com/ActiveState/cli/pull/2710/files#diff-7d9693c16c57a7c68d369e96c2969510a7193762c48b65c36e49b9d789669e2b.
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.
Ahhh that's the part I was missing. I was looking at my local zshrc_append file and wondering what you were looking to set up -.-
36a8781
to
55f933e
Compare
I expect more churn. |
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.
Sorry; I was not fully up to speed on what the test was trying to do. I now understand you need to set up the bashrc file with the new modifications you have introduced in this PR. This would normally happen as part of the installation, which it makes sense you want to avoid as part of this test.
Now that I understand this; it does seem like calling ConfigureAvailableShells()
is the most appropriate solution, as that matches what the installer does. I apologize as this was how you had done it at first; I sent us on a wild goose-chase and I'll own that.
I think long term we should actually do an "install" for a test like this, but at the moment all our install/update testing is already so fragile that it doesn't make sense to add to that problem.
I've filed DX-2153 to do what you suggest. I've already spent too much time on this ticket. As outlined in that ticket I filed, reverting back to I am open to tweaking what I currently have in this PR, but I don't want to revert too much because I feel it's going to waste more of our time. |
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.
Let's go with these changes. I forgot about the Setenv call; that is definitely something worth avoiding. Reading through the code it doesn't look too complicated to make subshell take a "home dir" argument in its constructor or something along those lines, but that is going to lead to refactorings which does feel like a bit of a scope creep. The story you filed sufficiently addresses the concern already, let's just address it there.
Thanks for bearing with me.
The PS1 prompt is only changed for the immediate subshell. Nested subshells do not inherit it, so it was not clear the user is still in an activated state.
cmd.exe does not need this because its PS1 equivalent is unmodified when opening another shell within a shell. I've also added a comment to the JIRA ticket explaining why I don't want to satisfy the Windows AC.