I have one jenkins build project which has one string argument on Linux, but it cannot receive Chinese string argument correctly. e.g. I try to print it using echo ${sql}, sql is my argument variable, I inut "北京", but jenkins shows in console output is below:
echo '??'
How to solve this problem?
How up to date is your version of Jenkins?
There was a patch back in May 2013.
Also, unicode for the console was more recently resolved on Sept 27.
If your Jenkins runs on Ubuntu, note that it uses the system locale at JVM startup time.
Hope that helps.
Related
I am attempting to run a Cucumber (Ruby 2.3) Test Suite from Jenkins that tests whether or not 2-4 byte UTF-8 characters are valid names for groups.
I have tried a number of solutions and have been searching for days attempting to find an issue relevant to mine.
The error that has been haunting me is:
incompatible character encodings: ASCII-8BIT and UTF-8 (Encoding::CompatibilityError)
Which refers to a line where I am attempting to send an ssh command to the CLI on the machine I am creating the group on:
$mymachine.cli_ssh.exec!("config group create --name='#{group_name}'")
Where within the exec!() command exists:
command.force_encoding("UTF-8")
The error only occurs when I am sending 2-4 byte UTF-8 characters, such that:
Group 'abcd' does not cause the error
and
Group 'ЯЯЯ' does cause the error
The problem:
Running this script on my local Ubuntu machine works perfectly fine (Ruby 2.2.1), as well as other machines in my area. (which is why I do not think it is necessary to provide more code than is given). I know there was a change in encoding to UTF-8 with the jump to Ruby 2.0 but both machines are past that, so I don't think that is the issue.
I have already tried establishing system locales on the Jenkins machine as en_US.UTF-8 both as locale system variables and within the /.bashrc file. No where have I seen an encoding variable set to ASCII-8BIT.
I have also tried exporting the system locales from the Jenkins shell prior to the script's execution.
I am in need of some answer, or some direction that can help me resolve this issue.
The issue was resolved by updating all Ruby gems on the Jenkins system. It is likely that certain gems were out of date even though they were technically compatible with the version of Ruby the Jenkins machine was running, and therefor, there could have existed Ruby code that was non-UTF8.
If you run into this issue in the future, I would recommend ensuring that all gem and ruby versions are consistent between your Jenkins machine and the working machine.
In Team Foundation Server 2015 Build (on-premise), I'm having issues running simple command line commands. All Command Line tasks simply fail with the following error: "File not found: ".
Take for example the following build definition:
This is executed using an on-premise Build Agent and will fail with the following exception in the logs:
BUILD FAILED
2016-01-20T12:04:47.5127709Z ##[warning]Filename doesn't indicate a full path to a executable file.
2016-01-20T12:04:47.5127709Z Executing the following commandline. (workingFolder = D:\_work\2\s)
2016-01-20T12:04:47.5127709Z date
2016-01-20T12:04:47.5127709Z Error message highlight pattern:
2016-01-20T12:04:47.5127709Z Warning message highlight pattern:
2016-01-20T12:04:47.5439748Z ##[error]File not found: date
Of course this is a simplified example where I simply want to output the current date using the date /t command. But the same problem occurs with all general command line commands which I've tried, such as dir, time, path etc. The MSDN does not provide any troubleshooting info on it, other than that the tool executed must reside in the PATH variable.
The issue is not specific to one build definition or repo; it can be reproduced on others as well.
The builds run as the built-in svc_tfsbuild account.
I'm perhaps thinking this is either a simple setting, or - wildly guessing - an issue related to rights, but cannot find any documentation where to look or what to check. Any help would be appreciated.
It appears this is a known issue on MS Connect as well.
In short a MSFT mentions the following:
Commands that are built-in to command prompt don't work. Anything resolvable based on your PATH/PATHEXT will work.
In the comment from 27 Oct, 2015 it is stated that this will be fixed in the next sprint. The mentioned workaround for now is simply executing cmd.exe first and provide the rest as arguments.
Using the example from the original question this would lead to:
Tool: cmd.exe
Arguments: /c "date /t"
And I can indeed confirm this works.
Does anyone know how to beat such chars in Jenkins console output log?
Seems there is a problem with UTF-8.
The issue here is that the characters are not being output as UTF-8 to your console. I think the solution is to tell jenkins when you invoke it to write output as UTF-8. See this solution for a similar problem UTF-8 char encoding does not work on console (Linux)
Something like
java -Dfile.encoding=UTF-8 jenkins.war might do the trick
In Jenkins ver. 2.46.2, I just got this to work by going to Nodes, Advanced settings, JVM Options and putting -Dfile.encoding=UTF8 and then taking that node offline and online again. Hope this helps other people. It would be great if UTF8 support was default.
To give the the answer more complete.
If you use an tomcat container to run jenkins, then edit catalina.sh config file:
vim apache-tomcat-path/bin/catalina.sh
Add -Dfile.encoding=UTF-8 to the JAVA_OPTS var and restart tomcat will do the trick.
For those who are using a build-agent and a pipeline, add this to the agent's dockerfile, and no further jenkins settings are needed
ENV JAVA_TOOL_OPTIONS -Dfile.encoding=UTF-8
Try to change the encoding with you are opening your file to 'utf-8' and check your encoding saved for the script in vs code(whatever platform)
enter image description here
I've tried everything with file.encoding variable, but didn't work.
My solution was to check environment locale variables in Jenkins Controller and Agent node where job is actually runing, and make them match.
In my case, agent node running the job required environment variable "LC_ALL=C.UTF-8", which was already defined in controller node.
More details here: https://stackoverflow.com/a/68217405/3284482
Try using AnsiColor plugin in Jenkins. This worked for me. I had tried all the above solutions but nothing happened. As I downloaded AnsiColor plugin everything got fixed!
My build failed when I had a hyphen in a variable name but succeeded when I changed it to an underscore.
The error was this but I could see in the online Workspace browser that it was valid and as mentioned above it succeeded with an underscore!
15:55:25 + MY-DISTRO=/home/jenkins/workspace/build-prod/my-distro
15:55:25 /tmp/hudson6751264218812911564.sh: line 3: MY-DISTRO=/home/jenkins/workspace/build-prod/my-distro: No such file or directory
What are valid characters for Jenkins variables names and where is this documented?
Judging by the .sh extension of the temporary script in the log you pasted, I assume you used the Execute shell build step in Jenkins - so in this case "valid" variable names mean variables in a linux shell script (the exact shell type might vary based on local configuration) - see for example this thread about allowed names on linux.
In case you have a windows slave, and use the Execute Windows batch command build step, you would of course have to check rules for windows variable names.
Also note that variables used in other places as these and similar build steps could potentially follow completely different rules (though sometimes they overlap). For example: if a plugin uses the Token Macro Plugin for evaluating expressions, you would have to refer to environmental variables with ${ENV,var="VARIABLENAME"}.
Jenkins is java based. Most probably it accepts java variable convention. I suggest avoid using $ in variable names since unix based operating systems treat it differently.
What Atilla said, but avoid dots (.) as well.
I'm attempting to sync Intellij's built in TFS plugin workspace with the one used by TEE's command line 'tf' command on OSX Mountain Lion and failing miserably.
This question appears to be very similar to mine, however it has no reference to what one should do when the computer name reported by each tool is different.
Intellij says my computer name is the fully qualified domain name (ex: hostname.domain.com) whereas the 'tf workspaces' command reports the computer name to be just the the hostname (ex: hostname). Consequently, they are unable to use the same workspace. I do know that you can change the computer name of a workspace, but I'd like to use both at the same time as we have some ant tasks using the 'tf' command locally. Our Windows users in the group are able to do this just fine.
Is there any way to make these tools report the same thing for the computer name? I believe I could then use the 'tf workspaces' command and enable me to use both at the same time in the same workspace. Much obliged.
It's not supported (according to the responsible developer). Please submit a request and we'll see what can be done to make it work.
Team Explorer Everywhere allows you to override your local hostname with the computerName system property. You can edit your tf launcher script to match what IntelliJ is using. You can change the last few lines of the file to be:
exec java -Xmx512M -classpath "$CLC_CLASSPATH" \
-DcomputerName=`hostname -f` \
"-Dcom.microsoft.tfs.jni.native.base-directory=$BASE_DIRECTORY/native" \
$RANDOM_DEVICE_PROPERTY com.microsoft.tfs.client.clc.vc.Main "$#"
If hostname -f does not actually report the same hostname that IntelliJ is determining, of course, you can simply hardcode that instead.