I have used "rebar generate" to create the package and move package to the test pc for running.
But when running the common test suite, I don't know how to "-env ERL_LIBS XXX" with "ct_run" command.
How to correct it?
ct_run -dir /home/peter/gate-0.0.1.20/lib/gate-0.0.1.20/ct -suite gate_test_data_SUITE.erl -erl_args -- -env ERL_LIBS gate-0.0.1.20/lib
This variable also works for the environment. Have you tried running the command as ERL_LIBS gate-0.0.1.20/lib ct_run -dir /home/peter/gate-0.0.1.20/lib/gate-0.0.1.20/ct -suite gate_test_data_SUITE.erl ?
Related
I get build errors when using mvn unleash:perform because it tries to use the default Java VM to build the release instead of the one pointed to with JAVA_HOME or the one which was used to start the maven-unleash-plugin.
With -Dunleash.releaseArgs="--debug=true" -X, I can see that the outer Maven uses Java 11 and the inner uses 8.
I tried to fix this with:
mvn unleash:perform -Dunleash.releaseEnvironment="JAVA_HOME=$JAVA_HOME" -X |& tee mvn.log
but that leads to an NPE:
Caused by: java.lang.NullPointerException
at com.itemis.maven.plugins.unleash.steps.actions.BuildProject.setupInvocationRequest (BuildProject.java:123)
at com.itemis.maven.plugins.unleash.steps.actions.BuildProject.execute (BuildProject.java:73)
Is changing the default VM in Windows my only option?
In my case, the culprit was in .mavenrc (Linux) or %USERPROFILE%\mavenrc_pre.cmd (Windows, also check %USERPROFILE%\mavenrc_pre.bat). There, JAVA_HOME was hardcoded to some specific path.
The fix is to a) only set JAVA_HOME when it has no value and b) to display a warning (with path) when the variable is set. That way, people can't get confused by some silent behavior.
Solution in .mavenrc:
if [[ -z "$JAVA_HOME" ]]; then
export JAVA_HOME=...
echo "~/.mavenrc: Setting JAVA_HOME to $JAVA_HOME"
fi
For %USERPROFILE%\mavenrc_pre.cmd, use:
if "%JAVA_HOME%"=="" (
set JAVA_HOME=...
echo %USERPROFILE%\mavenrc_pre.cmd: Setting JAVA_HOME to %JAVA_HOME%
)
I would like to test (from xonsh) if a command is available or not. If I try this from the xonsh command prompt:
which bash
Then it works:
user#server ~ $ which bash
/usr/bin/bash
But it does not work from xonsh script:
#!/usr/bin/env xonsh
$RAISE_SUBPROC_ERROR = True
try:
which bash
print("bash is available")
except:
print("bash is not available")
Because it results in this error:
NameError: name 'which' is not defined
I understand that which is a shell builtin. E.g. it is not an executable file. But it is available at the xnosh command prompt. Then why it is not available inside an xonsh script? The ultimate question is this: how can I test (from an xonsh script) if a (subprocess mode) command is available or not?
import shutil
print(shutil.which('bash'))
While nagylzs' answer led me to the right solution, I found it inadequate.
shutil.which defaults to os.environ['PATH']. On my machine, the default os.environ['PATH'] doesn't contain the active PATH recognized by xonsh.
~ $ os.environ['PATH']
'/usr/bin:/bin:/usr/sbin:/sbin'
I found I needed to pass $PATH to reliably resolve 'which' in the xonsh environment.
~ $ $PATH[:2]
['/opt/google-cloud-sdk/bin', '/Users/jaraco/.local/bin']
~ $ import shutil
~ $ shutil.which('brew', path=os.pathsep.join($PATH))
'/opt/homebrew/bin/brew'
The latest version of xonsh includes a built-in which command. Unfortunately, the version included will emit an error on stdout if the target isn't found, a behavior that is not great for non-interactive use.
As mentioned in another answer, which exists in the current version of xonsh (0.13.4 as of 15/12/2022) so your script would work. However, it outputs its own error message so it's necessary to redirect stderr to get rid of it.
Also, unless you redirect its stdout as well (using all>), it migh be a good idea to capture its output so the final version would look like this:
#!/usr/bin/env xonsh
$RAISE_SUBPROC_ERROR = True
try:
bash = $(which bash err> /dev/null)
print(f"bash is available: {bash}")
except:
print("bash is not available")
When I execute the printenv command on the go-agent
go#05f749b73185:/tmp$ printenv
HOSTNAME=05f749b73185
SHELL=/bin/bash
USER=go
LS_COLORS=
MAVEN_VERSION=3.3.9
MAIL=/var/mail/go
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games
MAVEN_HOME=/usr/share/maven
PWD=/tmp
JAVA_HOME=/usr/lib/jvm/java-8-openjdk-amd64/
LANG=en_US.UTF-8
HOME=/var/go
SHLVL=2
LOGNAME=go
LC_CTYPE=en_US.UTF-8
LESSOPEN=| /usr/bin/lesspipe %s
LESSCLOSE=/usr/bin/lesspipe %s %s
_=/usr/bin/printenv
But when I execute the printenv command from inside a job i get this result
06:57:26.482 [go] Start to execute task: <exec command="printenv" />.
06:57:26.493 GO_SERVER_URL=https://go-server:8154/go/
06:57:26.493 JAVA_HOME=/usr/lib/jvm/java-7-openjdk-amd64/jre
06:57:26.494 SHLVL=2
06:57:26.494 MAVEN_HOME=/usr/share/maven
06:57:26.495 LOG_DIR=/var/log/go-agent
06:57:26.495 GO_TRIGGER_USER=anonymous
06:57:26.495 GO_SERVER=go-server
06:57:26.496 GO_PIPELINE_LABEL=8
06:57:26.496 GO_STAGE_NAME=build
06:57:26.497 HOSTNAME=05f749b73185
06:57:26.497 PWD=/var/lib/go-agent
06:57:26.498 GO_STAGE_COUNTER=1
06:57:26.498 AGENT_WORK_DIR=/var/lib/go-agent
06:57:26.499 GO_JOB_NAME=Compile
06:57:26.499 MAVEN_VERSION=3.3.9
06:57:26.499 OLDPWD=/etc/service/go-agent
06:57:26.500 LC_CTYPE=en_US.UTF-8
06:57:26.500 AGENT_STARTUP_ARGS=-Dcruise.console.publish.interval=10 -Xms128m -Xmx256m -Djava.security.egd=file:/dev/./urandom
06:57:26.501 GO_FROM_REVISION=b6f8f0f3bedabe1cc0ffa1334c290f32da723cde
06:57:26.501 PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
06:57:26.501 GO_TO_REVISION=b6f8f0f3bedabe1cc0ffa1334c290f32da723cde
06:57:26.502 USER=go
06:57:26.502 GO_SERVER_PORT=8153
06:57:26.502 GO_PIPELINE_NAME=DropwizardSeed
06:57:26.503 HOME=/var/go
06:57:26.503 UID=103
06:57:26.503 GO_ENVIRONMENT_NAME=local
06:57:26.506 INITRD=no
06:57:26.507 GO_PIPELINE_COUNTER=8
06:57:26.508 GO_REVISION=b6f8f0f3bedabe1cc0ffa1334c290f32da723cde
06:57:26.509 LANG=en_US.UTF-8
If you look at the JAVA_HOME environment variable it's different between the job call and the call directly when you're logged in the machine.
This can be solved by setting the environment variable in the pipeline, but how can I configure my go-server and go-agents so I don't have to do this? What if I want to use another JDK as default?
Where does that JAVA_HOME environment variable come from?
Have you checked /etc/default/<agent-name>
In this file you can define the default values for an agent and you can also define environment variables using export command.
I am using following code to append ";C:\Python27" to environment variable PATH..
#echo off
Setx Path "%PATH%;C:\Python27" -M
PAUSE
but if i run this batch file more than once, it is appending ";C:\Python27" many times that should not happen.
SO i have to check for ;C:\Python27 before appending it to PATH variable.
Is there any command for this purpose?
The following Powershell should do it:
$needPython = $env:path | select-string -NotMatch -SimpleMatch "c:\python27"
if ($needPython) {
[Environment]::SetEnvironmentVariable("tstpath", $env:path + ";c:\python27", "User")
}
You can change User to Machine or Process to set a machine or process level environment variable.
You can run this directly from a powershell prompt.
If you're running this from a dos command line use (you need the full path to your script or .\ if it's in the current directory):
powershell "& '.\myscript.ps1'"
I downloaded and installed win32 yaws-1.98 installer for my win7 and tried to start it from windows command prompt with: yaws -i. the result I got is just as right below. where I have placed # was a simicolon.
Failed to create the process entirely.
Tried to invoke: erl.exe -pa "C:/Program Files/Yaws-1.98/ebin" -conf "C:\Program Files\Yaws-1.98\yaws.conf" -run yaws -yaws id default #
Make sure you have erl in your environment PATH
after some research, I placed the following paths in the O.S environment variables list separated by semicolon, first under the name ERL_LIBS and then PATH all with no change :
C:\Program Files\erl5.10.3\erts-5.10.3\bin
C:\Program Files\erl5.10.3\bin
what could I be missing
...s.b help.