I recently installed Jenkins, using Homebrew. I also installed Mercurial using Homebrew.
I can successfully clone an hg repo just fine - from Terminal. But if I try and do the same thing as part of a job in Jenkins, it fails.
So, in by job, I told Jenkins to run a shell script echo $PATH. Sure enough, the path /usr/local/bin is not there. If I execute the same command from Terminal, it's there.
So, what is the best way to modify PATH so that Jenkins is pulling the same PATH that I'm using, when I echo it from Terminal?
Note, Jenkins is running from the same user account that I'm logged into doing these tests, so I can't fathom why this is happening.
In your launchd .plist file for Jenkins, you can set the PATH environment variable by using the following:
<key>EnvironmentVariables</key>
<dict>
<key>PATH</key>
<string>(insert your path value here)</string>
</dict>
That should set the PATH to whatever you need.
For some reason, Jenkins doesn't keep /usr/local/bin in the PATH when connecting to a slave.
You can add it to the PATH either by
Adding an environment variable on the Node Configuration, or
Adding a .bashrc file on the user folder with
PATH="/usr/local/bin:${PATH}"
Note: The Mac client must be disconnected and then reconnected via the Jenkins web app after editing ~/.bashrc
I found that even setting the PATH environment variable for the node didn't work for the hombrew Mercurial installation. The path WOULD get set, but only for the script build phase, not for the VCS checkout phase. Here's what I wound up doing.
Go into Manage Jenkins -> Configure System
Add a new Mercurial Installation
Name it whatever you want (I named mine build-mac)
For Installation Directory I put /usr/local
The Executable parameter was pre-set to INSTALLATION/bin/hg, so I just left it at that.
Everything else in here can be left blank
Go into your job and edit the configuration
Under Source Code Management set Mercurial Version to the mercurial installation you just added.
Save
$$$
Hope that helps anyone else running into this same problem, now that we're not allowed (by default anyways) to do anything inside of /usr/bin anymore. Previously I would have just symlinked hg there, but now with the new "System Integrity Protection" "feature", that's no longer as trivial of task, and even more difficult if your Mac slave is headless.
You can set PATH in launchd.conf file. See here for details. Note that man launchctl says that 'commands can be stored in $HOME/.launchd.conf or /etc/launchd.conf to be read at the time launchd starts', so you probably can create '.launchd.conf' in your home directory and use instructions from the link with this file. But as far as I know in launchd.conf file you can't add directory to PATH, you can just rewrite PATH.
You can also see here for the solution using /etc/paths.d directory
There should be no space on either side of = in following PATH modification:
PATH="/usr/local/bin:$PATH"
I added it to my pre-build step on Jenkins installed on macOS.
Related
I've been having some issues installing the Heroku toolbelt on Windows 10, 64-bit.
It's the first time I install Heroku. I downloaded it from https://toolbelt.heroku.com/windows.
After installing, I tried launching a new Git Bash and typing heroku login but what I got back was bash: heroku: command not found
Running the same command on Windows Powershell, what I got back was
'MYSQL' is not recognized as an internal or external command,
operable program or batch file.
'MYSQL' is not recognized as an internal or external command,
operable program or batch file.
Any suggestions? I thought that googling those lines would help, but I haven't found much.
I followed the recommendation from here, but now when typing heroku login on the Powershell, nothing happens. Nothing changes on the Git Bash.
I checked, and the Heroku folder was added to the PATH.
I thought I'd ask for some help before installing anything else.
Thank you!
bash: heroku: command not found
The error message is clear: Bash cannot find the heroku command, it's not on your PATH.
I checked, and the Heroku folder was added to the PATH.
It seems you didn't check it correctly.
Note that even if it looks correct in the PATH settings window,
Git Bash might have a different PATH configured.
To see the PATH in Git Bash, run:
echo $PATH
When debugging path issues,
it's best to first run heroku with the absolute path. For example if it's in C:\Program Files\Heroku\bin\heroku then you can run in Git Bash with:
/c/Program\ Files/Heroku/bin/heroku login
If this works (and it should),
then you can add it to PATH like this:
PATH="$PATH:/c/Program\ Files/Heroku/bin"
Note that Heroku will likely need other programs too on the PATH,
such as MySQL and Ruby.
Find their absolute paths,
and add there directories to PATH the same way as heroku itself in the above example.
If instead of Git Bash,
you want to work in CMD,
the procedure is the same,
but the syntax to print and set PATH is different:
echo %PATH%
set PATH="C:\Program Files\Heroku\bin;%PATH%"
In windows bash instead of this
PATH="$PATH:/c/Program\ Files/Heroku/bin"
use this
PATH="$PATH:/c/Program Files/Heroku/bin"
My working solution (for git-bash especially) is:
alias heroku='winpty `where heroku.cmd`'
stored in .bashrc in home user dir
and them
heroku
works as expected
If using bash from VSCode, I had to restart VSCode, after installing heroku. If not using VSCode, you probably need to restart your bash terminal, after installing heroku.
In Control Panel\All Control Panel Items\System (if you are using Windows), go to Advanced system settings, and there in Environment Variables, you'll find two lists, on the same window, viz. System variables, and User variables for your system. Make sure you add your path, viz. C:/Program Files/Heroku/bin, in both of these lists.
I know this is an old thread and just want to share my solution.
Edit .bashrc for git-bash
alias heroku='"C:\Program Files\Heroku\bin\heroku.cmd" $#'
I am trying to get to install stardog on mac 10.8.5 using the instructions provided at http://docs.stardog.com/quick-start/.
The export path particular directory has been created and for which echo’ed to make sure that environmental variable is set up. The license key that is provided is also in the correct directory. When I try to run “$ ./stardog-admin server start” the command is not recognized. So I tried to create an export PATH to stardog’s bin, which did not work either.
I have also tried manually adding the path in the following:
- ~/.bash_profile
- ~/.profile
Still no luck, any ideas?
Using zsh I had a similar problem. For some reason, the docs suggest that from the stardog-directory-name directory you can run the command, but it didn't work until you cd into the bin directory. Once there ./stardog-admin server start should run correctly.
It sounds like you simply have something incorrect in your .bash_profile or .profile. If you run either of the stardog scripts from it's bin directory, it will work. If you're getting a command not recognized error, that sounds like bash cannot find the stardog-admin script.
After installing Heroku Toolbelt, Cygwin is no longer executing .bashrc How do I fix this?
This heroku/toolbelt issue on github Creates/overwrites ENV['HOME'] on Windows, which breaks Cygwin says to
Renaming HOME to %USERPROFILE% evidently fixes this
My HOME System Properties Variable is already named %USERPROFILE%.
Being a noobie I focused on a PATH issue. I began changing my System Path Variable to include the .bashrc PATH
C:\cygwin\home\usermatt
I then tried various system PATH variables, one at a time, restarting my machine each time:
C:\cygdrive\c\home\usermatt\
C:\home\usermatt\
C:\cygwin\c\home\usermatt\
Cygwin's pwd on startup is /cygdrive/c/Users/usermatt. I tried moving .bashrc here without success.
The Cygwin FAQs and the comments in the file itself warn of problems after editing the etc/profile file and I did not try this.
All was well before installing Heroku Toolbelt. How can I get Cygwin to find the .bashrc file?
According to the link you provided:
you need to remove the HOME environment variable from the system
properties. Look how to set/remove variables from Windows permanently.
This will depend on your Windows OS, but in general:
Right click on your "Computer" and select Properties
Click on "Advanced System Settings"
Click on "Environment Variables..."
Find and delete the Home variable
OK your way out and try Cygwin again
I had run the MacPorts installer (2.0.3) for my OS X Leopard (10.5.8) which finished "successfully". Unfortunately the port command was not available so I looked in the MacPorts Guide which says that the installer should have run a so-called "postflight" script that sets the necessary environment variables. I tried to run the postflight script manually (which I downloaded from here), but the execution fails with the following output:
Detected the bash shell.
Your shell already has the right PATH environment variable for use with
MacPorts!
Your shell already has the right MANPATH environment variable for use with
MacPorts!
Your shell already has the right DISPLAY environment variable for use with
MacPorts!
Adding [default] tag to sources.conf if needed...
couldn't read file "/Contents/Resources/upgrade_sources_conf_default.tcl": no
such file or directory
Updating port image format...
couldn't read file "/Contents/Resources/images_to_archives.tcl": no such file or
directory
Synchronizing the MacPorts installation with the project's rsync server...
-bash: __PREFIX__/bin/port: No such file or directory
An attempt to synchronize your recent MacPorts installation with the project's
rsync server failed!
Please run 'sudo port -d selfupdate' manually to find out the cause of the
error.
You have succesfully installed the MacPorts system, launch a terminal and try it
out!
Read the port(1) manual page and http://guide.macports.org for help,
http://www.macports.org/contact.php if you need to get in touch with The
MacPorts Project.
Any ideas?
First invoke the port command directly:
$ /opt/local/bin/port help
If that comes back with something reasonable (like the help text) then it's just that your $PATH isn't being used by your current shell. Try logging off and back on again to resolve that in the short term (this will test that your .bashrc file is correctly configured) or you could just modify the PATH environment variable directly (which doesn't test .bashrc):
$ export PATH=$PATH:/opt/local/bin
You downloaded the postflight script but it alone cannot access the accessory scripts in Contents/ because those are located into the install package.
Those missing Tcl scripts are for upgrading from an older install, the log says PATH was already correctly configured but the macports bin directory could have the wrong position in PATH variables, for instance being at the end of PATH.
If you are doing a fresh install you can just only need PATH and MANPATH -you want man pages provided by macports before system's ones- as per [1]
[1] http://guide.macports.org/#installing.shell.postflight
I'm a Mac newbie and just upgraded to Node.js 0.67. After running node, the installer says "Make sure that /usr/local/bin is in your $PATH."
And I try to run node but as expected, it doesn't run without the path change.
So not really knowing what I'm doing (yes!), after some research I do this:
export "PATH=/usr/local/bin"
And node runs. But sudo doesn't. Which I think means I screwed up the environment variables.
sudo: command not found
Then in another Terminal window (that was open when I messed this up), sudo does respond; both windows have the same path. But in that window, npm is no longer available.
Can anyone help get me back to sudo stability?
sudo on a Macintosh lives in /usr/bin.
Make sure /usr/bin is in your $PATH environment and you should be okay.
And to do that, in the context of your question above, do something like:
export "PATH=$PATH:/usr/local/bin"
The idea here being that you are appending a new search path to the already existing list in your PATH environment variable.
Here is a potentially useful tutorial you can refer to.