I have the usual section
variables:
DESTINATION: "dev"
dev-SERVERNUMBERS: "0 1"
And, this had been working all long and suddenly. Gitlab CI is complaining and giving the following error message
/bin/bash: line 103: export: `dev-SERVERNUMBERS=0 1': not a valid identifier
Initially, I thought I was exporting something wrong. But, it looks like that is how gitlab runners work they export your variables to make them available to all jobs within your pipeline. I have NO export statement within any before_script.
I can understand why it is complaining because it expects the variable to have double quotes around it in order to export. But, it DID NOT complain now for atleast 2 months, so I cannot understand why now ?
I find gitlab-ci just so unpredictable and extremely frustrating to use. By now, if I had automated this build of mine via shell scripts I would have be on my way. And, I have been stuck on this error for 3 days now. It does not even print out any debug echos that I have set up and straight away gives this line number which has nothing to do with my .gitlab-ci.yaml
At the very least it should give the verbose command that is trying to execute.
Bash is complaining about the environment variable name (the identifier) not necessarily the value. - is not an allowed character in environment variable names. You can only use alphanumerics (a-Z, 0-9), and underscores (_).
This is a limitation of bash, not GitLab CI.
export foo="0 1" # OK
export foo-bar="0 1" # Not OK
bash: export: `foo-bar=0 1': not a valid identifier
Related
I'm tinkering with this project where Step 6 requires me to run a command like make db-prepare-artix7. This command corresponds to this section of the Makefile. I am confused by the #+SKIP_ENV=true in the recipe. What is #+SKIP_ENV here, and what does it do? Couldn't find anywhere referring to SKIP_ENV.
Thanks!
Explaining every part:
The # means the command will not be echoed by Make during recipe execution
The + means the command will be executed even during dry runs: make --dry-run ...
The SKIP_ENV=true is sh(ell) syntax for setting the environment variable SKIP_ENV to the string true for the duration of the command that follows
In your case the source ... command
The effect of SKIP_ENV depends on the command - dig deeper to find out
When defining a Bamboo plan variable, the page has this.
For task configuration fields, use the syntax
${bamboo.myvariablename}. For inline scripts, variables are exposed as
shell environment variables which can be accessed using the syntax
$BAMBOO_MY_VARIABLE_NAME (Linux/Mac OS X) or %BAMBOO_MY_VARIABLE_NAME%
(Windows).
However, that doesn't work in my Linux inline script. For example, I have the following defined a a plan variable
name: my_plan_var value: some_string
My inline script is simply...
PLAN_VAR=$BAMBOO_MY_PLAN_VAR
echo "Plan var: $PLAN_VAR"
and I just get a blank string.
I've tried this
PLAN_VAR=${bamboo.my_plan_var}
But I get
${bamboo.my_plan_var}: bad substitution
on the log viewer window.
Any pointers?
I tried the following and it works:
On the plan, I set my_plan_var to "it works" (w/o quotes)
In the inline script (don't forget the first line):
#/bin/sh
PLAN_VAR=$bamboo_my_plan_var
echo "testing: $PLAN_VAR"
And I got the expected result:
testing: it works
I also wanted to create a Bamboo variable and the only thing I've found to share it between scripts is with inject-variables like following:
Add to your bamboo-spec.yaml the following after your script that will create the variable:
Build:
tasks:
- script: create-bamboo-var.sh
- inject-variables:
file: bamboo-specs/vars.yaml
scope: RESULT
# namespace: plan
- script: echo ${bamboo.inject.GIT_VERSION} # just for testing
Note: Namespace defaults to inject.
In create-bamboo-var.sh create the file bamboo-specs/vars.yaml:
#!bin/bash
versionStr=$(git describe --tags --always --dirty --abbrev=4)
echo "GIT_VERSION: ${versionStr}" > ./bamboo-specs/vars.yaml
Or for multiple lines you can use:
SW_NUMBER_DIGITS=${1} # Passed as first parameter to build script
cat <<EOT > ./bamboo-specs/vars.yaml
GIT_VERSION: ${versionStr}
SW_NUMBER_APP: ${SW_NUMBER_DIGITS}
EOT
Scope can be local or result. Local means it's only available for current job and result means it can be used in subsequent stages of this plan and releases that are created from the result.
Namespace is just used to avoid naming collisions with other variables.
With the above you can use that variable in later scripts with ${bamboo.inject.GIT_VERSION}. The last script task is just to see that it is working in other scripts. You can also see the variables in the web app as build meta data.
I'm using the above script before the build (in my case compiling C-Code) takes place so I can also create a version.h file that can be used by the source code.
This is still a bit cumbersome but I'm happy with it and I hope it will help others to configure Bamboo. Bamboo documentation could be better. (Still a lot try and error)
First of all I should point out I'm new to Atlassian's Bamboo and continuous integration in general. This is the first project where I've used either.
I've created a raft of unit tests using the tSQLt framework. I've also configured Bamboo to:
Get a fresh copy of the repository from BitBucket
Drop & re-create the build DB
Use Red-Gate SQL Compare to deploy the DB objects from source to the build DB
Run the tSQLt tests
Output the results of the tests in XML format to a file called TestResults.xml
I've checked and can confirm that the TestResults.xml file is created.
In Bamboo I then added a JUnit Parser task to consume the contents of this TestResults.xml file. However when that task runs it returns this error:
Failed to parse test result file
At first I thought it might have meant that Bamboo could not find the file. I changed the task that created the results file to output a file called TestResults2.xml. When I did that the JUnit Parser returned this error:
Failing task since test cases were expected but none were found.
So I'm assuming that the first error message means Bamboo is finding the file, it just can't parse the file.
I have no idea where to start working out what exactly is the problem. Has anyone got any ideas?
I had a similar problem, but turned out to be weird behavior from bamboo needing file stamps being modified to have visibility of the JUnit file.
In Windows enviornment you just need to add "script task" before the "JUnit task"
powershell (ls *.xml).LastWriteTime = Get-Date
Reference
https://jira.atlassian.com/browse/BAM-12768
I have had several cases of this and was able to fix it by removing single quotes and greater than / less than characters from test names inside the *.rb file.
Example
test "make sure 'go_to_world' is removed from header and length < 23"
change to remove single quotes and < symbol
test "make sure go_to_world is removed from header and length less than 23"
Very common are contractions: "won't don't shouldn't", or possessives: "the vessel's data".
And also < or > characters.
I think there is a bug in the parser that just doesn't escape those characters in a test title appropriately.
I was originally trying to run an executable (tftpd32.exe) from Expect with the following command, but for some unknown reason it would hanged the entire script:
exec c:/tftpd32.351/tftpd32.exe
So, decided to call a batch file that will start the executable.
I tried to call the batch file with the following command, but get an error message stating windows cannot find the file.
exec c:/tftpd32.351/start_tftp.bat
I also tried the following, but it does not start the executable:
spwan cmd.exe /c c:/tftpd32.351/start_tftp.bat
The batch file contains this and it run ok when I double click on it:
start tftpd32.exe
Any help would be very much appreciated.
Thanks
The right way to run that program from Tcl is to do:
set tftpd "c:/tftpd32.351/tftpd32.exe"
exec {*}[auto_execok start] "" [file nativename $tftpd]
Note that you should always have that extra empty argument when using start (due to the weird way that start works; it has an optional string in quotes that specifies the window title to create, but it tends to misinterpret the first quoted string as that even if that leaves it with no mandatory arguments) and you need to use the native system name of the executable to run, hence the file nativename.
If you've got an older version of Tcl inside your expect program (8.4 or before) you'd do this instead:
set tftpd "c:/tftpd32.351/tftpd32.exe"
eval exec [auto_execok start] [list "" [file nativename $tftpd]]
The list command in that weird eval exec construction adds some necessary quoting that you'd have trouble generating otherwise. Use it exactly as above or you'll get very strange errors. (Or upgrade to something where you don't need nearly as much code gymnastics; the {*} syntax was added for a good reason!)
I'm using xcodebuild inside a bash script on a continuous integration server.
I would like to know when a build as failed in the script, so I can exit prematurely from it and mark the build as failed.
xcodebuild displays a BUILD FAILED message to the console, but I don't succeed in getting a return value.
How can I achieve this?
Thanks in advance
I solved my problem using this command: xcodebuild -... || exit 1
You can use the "$?" variable to get the return code of the previous command.
xcodebuild -...
if [[ $? == 0 ]]; then
echo "Success"
else
echo "Failed"
fi
xcodebuild always returns 0, regardless of the actual test result. You should check for either ** BUILD FAILED ** or ** BUILD SUCCEEDED ** in the output to know whether tests pass or not.
Xcodebuild can return any of the error codes listed below and not restricted to EX_OK (or int 0).
However, I learnt from solution provided by Dmitry and modified as following. It works for me and I hope it could be helpful.
xcodebuild -project ......
if test $? -eq 0
then
echo "Success"
else
echo "Failed"
fi
Error codes
The following are the error codes that can be returned by sysexits archive:
EX_OK (0): Successful exit.
EX_USAGE (64): The command was used incorrectly, e.g., with the wrong number of arguments, a bad flag, a bad syntax in a parameter, or whatever.
EX_DATAERR (65): The input data was incorrect in some way. This should only be used for user's data and not system files.
EX_NOINPUT (66): An input file (not a system file) did not exist or was not readable. This could also include errors like ``No message'' to a mailer (if it cared to catch it).
EX_NOUSER (67): The user specified did not exist. This might be used for mail addresses or remote logins.
EX_NOHOST (68): The host specified did not exist. This is used in mail addresses or network requests.
EX_UNAVAILABLE (69): A service is unavailable. This can occur if a support program or file does not exist. This can also be used as a catchall message when something you wanted to do doesn't work, but you don't know why.
EX_SOFTWARE (70): An internal software error has been detected. This should be limited to non-operating nonoperating operating system related errors as possible.
EX_OSERR (71): An operating system error has been detected. This is intended to be used for such things as cannot fork'',cannot create pipe'', or the like. It includes things like getuid returning a user that does not exist in the passwd file.
EX_OSFILE (72): Some system file (e.g., /etc/passwd, /var/run/utmp, etc.) does not exist, cannot be opened, or has some sort of error (e.g., syntax error).
EX_CANTCREAT (73): A (user specified) output file cannot be created.
EX_IOERR (74): An error occurred while doing I/O on some file.
EX_TEMPFAIL (75): Temporary failure, indicating something that is not really an error. In send-mail, sendmail, mail, this means that a mailer (e.g.) could not create a connection, and the request should be reattempted later.
EX_PROTOCOL (76): The remote system returned something that was ``not possible'' during a protocol exchange.
EX_NOPERM (77): You did not have sufficient permission to perform the operation. This is not intended for file system problems, which should use EX_NOINPUT or EX_CANTCREAT, but rather for higher level permissions.
EX_CONFIG (78): Something was found in an unconfigured or misconfigured state.
For more info click here.
Maybe it's not because of the xcodebuild not returning non-zero when build failed. Your shell script continuing to run regardless of the returning-error line might be the result of that you didn't run the script with a "-e" option.
Try put #!/bin/bash -e ahead of the script file.
Generally, you can always check the exist value for the last run process in Unix bash by:
$ echo $?
where $? is a built-in placeholder of the exist value of last executed command. For more details about other bash's built-in variables see here.
So, first run your command you want to investigate its return code, then run echo as above.
Whether the compiled product （.a or .ipa file）exists