Closed r4v5 closed 6 years ago
Plugging into the sh
and bat
steps had been my original goal when I was first working on this plugin; however I didn't find a way to accomplish this. I attempted to intercept the sh
and bat
commands in order to conditionally manipulate them; however, it appears that Jenkins doesn't allow this kind of behavior (with good reason, it could potentially lead to very difficult to trace issues).
Since virtualenv works primarily through the manipulation of environmental variables, it is theoretically possible to supply the manipulated environment to each sh
command that occurs within the block; however, I didn't see a good way to accomplish this either, short of reimplementing virtualenv myself.
This is why I made the decision to use pysh
and pybat
instead.
Actually, after poking around some more, there may be a way to accomplish this. I need to mess around with it, and will report back here
After poking around a bit, I believe that I can capture the relevant changes in EnvVars that the virtualenv makes, and make those changes available within the body of withPythonEnv
. Doing so would allow sh
and bat
steps to access the virtualenv as requested.
Life has been getting in the way recently, and I apologize for the delay. As soon as I get a little extra time I will knock this out
Awesome news about possibly being able to do it with environment variables! I understand life getting in the way. Take your time; in the meantime, it's just two more characters for us to type, it's not more important than the rest of your life.
This functionality has been added, and will be released shortly as version 2.0.0
This plugin is useful, but multiple people in my organization, when trying it, have missed the fact that any commands you want to run within a virtualenv must be invoked as
pysh
steps instead of regularsh
. The typical behavior we've come to expect for withSomething{} pipeline blocks (withEnv, withCredentials, etc) has been that they affect the behavior of every shell command within the block; is there a reason (technical or philosophical) for separating out that behavior in this plugin?