I'm trying to run a test script in an azure devops pipeline. I have a test that runs on my own environment but fails in the pipeline.
when I run the following code:
command = '['latexmk', '-pdf', '--interaction=nonstopmode', '/tmp/my_tex.tex']'
output = subprocess.check_output(command,
stderr=subprocess.STDOUT,
**check_output_kwargs)
Locally it finishes without errors. When I run it in the DevOps pipeline I get:
subprocess.CalledProcessError:
Command '['latexmk', '-pdf', '--interaction=nonstopmode', '/tmp/tmp78wpkv3l/Unknown.tex']'
returned non-zero exit status 12.
Which isn't very descriptive. Does anybody know how to solve this or get more descriptive error messages?
The problem was that latexmk was being run in the wrong folder, fixed with a simple os.chdir(<correct folder>)
Related
I have an ADO pipeline which starts a JMeter script execution on a VM(load-generator) using a Command Line task. Following is the command line statement -
C:\JMeter\apache-jmeter-5.2.1\bin\jmeter -n -f -t "$(Build.SourcesDirectory)\JMeterTestScripts\$(Module)\$(TestName).jmx" -l "$(Build.ArtifactStagingDirectory)\$(TestName).jtl"
I am using the ultimate thread group for one of my test scripts.
The JMeter executable folder on the VM has all the necessary plugin-related JARs present in the lib/ext folder. But for some reason while trying to run this pipeline, it throws the following error-
*An error occurred: Error in NonGUIDriver Problem loading XML from:'C:\agent\_work\1\s\Jmeter_Script_Folder\ScriptName.jmx Cause:
CannotResolveClassException: kg.apc.jmeter.threads.UltimateThreadGroup*
However, when I try to execute the same command from the VM (load generator) manually using the windows cmd, then it successfully triggers the test execution.
Any idea, what possibly could be causing this odd behaviour? Any pointers on this is much appreciated.
I tried to execute two Power-shell script. 1st one is incorrect and 2nd one is correct but bamboo shows Successful build.
It really depends why the first script is "incorrect". If it is throwing an error code, by default it will still return a success, as the script successfully ran, even if the results were an error. You might want to look into using $LastExitCode after you call the Powershell script to get the status of the script itself.
i am trying to run Pact broker can i deploy tool with paramaters which is working fine locally but when i add the build step in TeamCity it is throwing below error
Start-Process : This command cannot be run due to the error: The
system cannot find the file specified.
when i run the same powershell script locally, it is working fine .
powershell script:
CanIDeploy.bat code is
Note: the reason i am calling pact-broker.bat from power shell script is, unable to run bat file from Teamcity , that is the reason created powershell script which internally calls pact broker bat file.
any help is appreciated
I see that you use relative path, but what about the working directory? I see a different path in the error message vs what you show where the file is.
I have a powershell build script that I am executing from Gitlab CI Pipelines.
When run manually (on the build server) the build script runs fine, but when executed by the Gitlab CI runner it:
Times out after an hour (runs for about 20 mins if run manually)
Does not echo Write-Output statements into the build log
So there is something going wrong when executed from Gitlab CI. However, as the Write-Output statements aren't displayed in the Build Log there is no real way to troubleshoot this.
What do I need to do to get the Write-Output statements to display in the build log? I would have assumed any STDOUT messages would show there, but they're not coming through.
The answer here was to set PowerShell as the shell to use in the gitlab runner.
This is done by adding the following line to the gitlab runners config.toml file:
shell = "powershell"
Now the file executes correctly and Write-Output statements are echo'ed in the build log.
When putting together a release definition in VSO, adding an Azure PowerShell
task
backed by a file Script1.ps only containing exit 1 does not fail the step when it runs - which I would expect it to do, given that the Continue on error box is not checked
If I add the PowerShell task, writing exit 1 using the inline variant would indeed fail the step. This also comes with an 'advanced configuration option' where the Fail on Standard Error is checked by default.
What did I miss? How would I go about making the Azure Powershell fail in the same manner?
Using this code instead:
[Environment]::Exit(1)
The task will fail if the script throws an exception or writes to stderr stream.