SAP WebIDE MTA New Build fails since last days with weird zipping issue - sap-cloud-platform

Our SAP MTA project fails to build since a day or 2 using the new cloud mta build tool option with the following strange error ( I have renamed our actual project name with 'xxx') :
11:00:22 (Executor) [2020-02-06 10:00:22] INFO generating the MTA archive...
11:00:35 (Executor) [2020-02-06 10:00:35] INFO the MTA archive generated at: /projects/xxx/mta_archives/xxx_cloud_v1_1.0.0.mtar
11:00:35 (Executor) [2020-02-06 10:00:35] INFO cleaning temporary files...
11:00:35 (Executor) /usr/local/scripts/mbt/webide_mbt_build.sh: line 105: [: mta_archives/xxx_cloud_v1: binary operator expected
11:00:35 (Executor) zip warning: name not matched: mta_archives/xxx_cloud_v1
11:00:35 (Executor) zip warning: name not matched: true_1.0.0.mtar
11:00:35 (Executor)
11:00:35 (Executor) zip error: Nothing to do! (try: zip -r mta_archives/mta_archives.zip . -i mta_archives/xxx_cloud_v1 true_1.0.0.mtar)
11:00:35 (Executor) ERROR:The build of project xxx_cloud_v1 true failed, (Error Code=12, Error Msg=Failed to compress the mta_archives/xxx_cloud_v1 true_1.0.0.mtar source file to the mta_archives/mta_archives.zip .zip file.)
11:00:35 (Executor) ERROR:Function call stack
11:00:35 (Executor) exitOnError
11:00:35 (Executor) zipFile
11:00:35 (Executor) main`
It seems like it is confused about the name and adds a space and the value true in between .. causing the ZIP script command to faile.
I have rechecked our MTA.yaml file but don't see anything weird with it.
Other test projects build just fine so it has to be somethinig with either our project work space and/or the script ?
If I try to use the other older build tool option then I am getting a similar script issue:
11:19:56 (Executor) The "Task for mta build" process started.
11:19:59 (Executor) Starting process: "cd /projects/xxx_cloud_v1; webide_mta_build.sh"
11:19:59 (Executor) Incorrect command line syntax
11:19:59 (Executor) SAP Multitarget Application Archive Builder 1.1.20
We are on SAP Web IDE Full-Stack - Version: 200116. Production env.
Thanks,
Steven

I have been going through all the changes we made on the project over the last couple of days and found the potential source of the issue - although I cannot explain why this is happening.
So for future reference - here is what I found:
We are using quite some properties in the MTA.yaml file and a couple new ones where added.
So
properties:
XS_APP_LOG_LEVEL: debug
CUSTOM_PROP_1: true
CUSTOM_PROP_2: true
It seems that one of those properties is causing the issue - although there is nothing strange with it and it has a boolean value like many others we have.
I first thought it would be too long or the combined length would exceed some script variable ... but I can't come to a conclusive answer.
Will be checking with our SAP contacts for further clarification.

Related

VS Code and pytest: Where is the default junit-xml output path defined and why is there one?

I am trying to run a debug the tests of my Python project inside the VS Code interface.
I followed the instruction from VS Code's website using pytest but when trying to run a test the output fails:
============================= test session starts =============================
platform win32 -- Python 3.8.10, pytest-6.2.4, py-1.10.0, pluggy-0.13.1
rootdir: c:\Users\myUserName\Projects\myProjectName
plugins: localserver-0.5.0
collected 1 item
myProjectName\tests\test_static_analysis.py . [100%]
- generated xml file: C:\Users\MYUSERNAME\AppData\Local\Temp\tmp-26696NTXW7ChqfMEN.xml
-
============================== 1 passed in 0.18s ==============================
Error: Error: cannot open file:///c%3A/Users/myUserName/Projects/myProjectName/C. Detail:
Unable to read file 'c:\Users\myUserName\Projects\myProjectName\C' (Error: Unable to resolve
non-existing file 'c:\Users\myUserName\Projects\myProjectName\C')
Error: Error: cannot open file:///c%3A/Users/myUserName/Projects/myProjectName/C. Detail:
Unable to read file 'c:\Users\myUserName\Projects\myProjectName\C' (Error: Unable to resolve
non-existing file 'c:\Users\myUserName\Projects\myProjectName\C')
Maybe VS Code doesn't have the authorization to write in AppData.
What concerns me is why is VS Code launching pytest with a junit-xml output option?
The command actually executed by VS Code is:
c:; cd 'c:\Users\myUserName\Projects\myProjectName'; & 'C:\ProgramData\Anaconda3\envs\venv-myProjectName\python.exe' 'c:\Users\myUserName\.vscode\extensions\ms-python.python-2021.8.1105858891\pythonFiles\lib\python\debugpy\launcher' '53774' '--' 'c:\Users\myUserName\.vscode\extensions\ms-python.python-2021.8.1105858891\pythonFiles\testlauncher.py' 'c:\Users\myUserName\Projects\myProjectName' 'pytest' '--override-ini' 'junit_family=xunit1' '--rootdir' 'c:\Users\myUserName\Projects\myProjectName' '--junit-xml=C:\Users\MYUSERNAME\AppData\Local\Temp\tmp-26696pYh1w3pF2cXx.xml' './myProjectName/tests/test_static_analysis.py::TestStaticAnalysisVesselForceOnLateralCenter::test_pos_surge_on_vessel'
When going in Settings > python.testing.pytestArgs it is empty.
Where is this output path defined?
How can I change it to be in the local working directory?
Do I need to have a junit-xml output? Is it mandatory for VS Code UI to work?

Unknown command error in Jenkins when running Cake script using Powershell

Our Jenkins server has been successfully building projects for years using Powershell to run a cake script. Out of the blue today, we started getting the following error on multiple projects:
12:10:46 Running build script...
12:10:46
12:10:46 Error: Unknown command 'Default'.
12:10:46
12:10:46 .\scripts\build.cake -target=Default -configuration=Release
12:10:46 -verbosity=Verbose -environment=dev -certificatePath=C:/Program Files
12:10:46 (x86)/xxxxx/Verisign Certificate -certificateName=xxxxxxxx_cert.pfx
12:10:46 -certificatePassword=xxxxxxxxxxx
12:10:46 ^^^^^^^ No such command
12:10:46
12:10:47 Build step 'Windows PowerShell' marked build as failure
The build.ps1 script has not changed. The build.cake script has not changed. Jenkins was not updated since the last successful builds nor any of the add-ins.
If I remove "-target=Default" from the argument list, I just get the same error on "-configuration=Release" indicating unknown command: "Release".
Has anyone else experienced this?
The possible root cause of this failure is the cake version update (0.38.x --> 1.0)
You have two ways to fix this issue
Change the Argument Syntex - arguments should always be called with multi-dash syntax (e.g. --target=Foo) instead of (e.g. -target=Foo)
Refer: https://cakebuild.net/docs/getting-started/upgrade
Pinning the cake version
Specified the version of Cake in the tools/packages.config file
Refer: https://cakebuild.net/docs/writing-builds/reproducible-builds/pinning-cake-version

Continue after a failing command in appveyor

In appveyor I use the statement:
- initexmf --admin --force --mklinks
but due to a problem it gives the message:
initexmf --admin --force --mklinks
Sorry, but "MiKTeX Configuration Utility" did not succeed for the following reason:
Script configuration file not found.
The log file hopefully contains the information to get MiKTeX going again:
C:\ProgramData\MiKTeX\2.9\miktex\log\initexmf_admin.log
The system cannot find the path specified.
Command exited with code 1
due to the error code the process terminates and I cannot type the C:\ProgramData\MiKTeX\2.9\miktex\log\initexmf_admin.log anymore, so a bit hard to debug ...
questions:
How to continue after an error
How to stop after the outputting the file (exit 1 ?)
To run a script on failure use on_failure section, for example to push initexmf_admin.log to artifacts:
on_failure:
- appveyor PushArtifact C:\ProgramData\MiKTeX\2.9\miktex\log\initexmf_admin.log

lvcGame, VBS and HLA setup Error 127 out of LVCGame

I am trying to setup VBS to talk HLA to a legacy app using LVCGame.
I am using openRTI currently in my project. I have LVCGame pointed to a directory with the following dlls:
RTI-NG.dll
OpenRIT.dll (copied from another folder)
libRTI-NG.dll (copy of RTI-NG.dll and renamed)
FedTime.dll
My vbsClient.config relevant lines:
Plugins = HLA-1.3.dll : HLA-1.3\Project\HLA.config
I am getting the following error out of LVCGame:
2014-12-31 10:48:03 INFO (LVCGAME::LVCGame::init) Initialised.
2014-12-31 10:48:03 ERROR (LVCGAME::LVCGame::start) 'class LVCGAME::UTILS::Exception' (src\LVCGame.cpp, line 766): Couldn't load plugin .\lib\HLA-1.3.dll. Error Code: 127
I did send an email to VBS support but it I had any idea what a 127 error was maybe I could get further.
I found that another free RTI Portico implementation is mentioned as working with LVCgame giving that a try has pretty similar results I get and error 126 instead of a 127.
2015-01-02 09:47:47 INFO (LVCGAME::UTILS::IOUtils::extractDllLoadPath) Using DLL path specified as 'D:\Program Files (x86)\Portico\portico-2.0.1\bin\vc10'.
2015-01-02 09:47:47 INFO (LVCGAME::LVCGame::init) Initialised.
2015-01-02 09:47:47 ERROR (LVCGAME::LVCGame::start) 'class LVCGAME::UTILS::Exception' (src\LVCGame.cpp, line 766): Couldn't load plugin .\lib\HLA-1.3.dll. Error Code: 126
2015-01-02 09:47:47 ERROR (LVCGAME::LVCGame::start) LVCGame start failed!
So eventually I found that Portico was creating a log file located in my VBS directory\logs. From there I was able to see that Portico at least was not able to find my .fed file I had the path messed up.

Hudson failing build w/o revealing cause

Every build has failed as of Tuesday. I'm not exactly sure what happened. The Phing targets (clean/prepare) are being executed properly. Additionally, the unit tests are passing with flying colors, with only a warning for duplicate code (not a reason for a fail). I tried removing the phpDoc target to see if that was causing the error, but the build still failed.
Started by user chris Updating
file://localhost/projects/svn/ips-com/trunk
At revision 234 no change for
file://localhost/projects/svn/ips-com/trunk
since the previous build [trunk] $
/opt/phing/bin/phing clean prepare
-logger phing.listener.NoBannerLogger Buildfile:
/var/lib/hudson/.hudson/jobs/IPS/workspace/trunk/build.xml
IPS > clean:
[echo] Clean... [delete] Deleting directory
/var/lib/hudson/.hudson/jobs/IPS/workspace/build
IPS > prepare:
[echo] Prepare...
[mkdir] Created dir: /var/lib/hudson/.hudson/jobs/IPS/workspace/build
[mkdir] Created dir: /var/lib/hudson/.hudson/jobs/IPS/workspace/build/logs
[mkdir] Created dir: /var/lib/hudson/.hudson/jobs/IPS/workspace/build/logs/coverage
[mkdir] Created dir: /var/lib/hudson/.hudson/jobs/IPS/workspace/build/logs/coverage-html
[mkdir] Created dir: /var/lib/hudson/.hudson/jobs/IPS/workspace/build/docs
[mkdir] Created dir: /var/lib/hudson/.hudson/jobs/IPS/workspace/build/app
BUILD FINISHED
Total time: 1.0244 second
[workspace] $ /bin/bash -xe
/tmp/hudson3259012225710915845.sh
+ cd trunk/tests
+ /usr/local/bin/phpunit --verbose -d memory_limit=512M --log-junit
../../build/logs/phpunit.xml
--coverage-clover ../../build/logs/coverage/clover.xml
--coverage-html ../../build/logs/coverage-html/
PHPUnit 3.5.0 by Sebastian Bergmann.
IPS Default_IndexControllerTest .
Default_AuthControllerTest ......
Manage_UsersControllerTest .....
testDeleteInvalidUserId ..
testGetPermissionsForInvalidUserId .. Audit_OverviewControllerTest
............
Time: 14 seconds, Memory: 61.00Mb
[30;42m[2KOK (28 tests, 198
assertions) [0m[2K Writing code
coverage data to XML file, this may
take a moment.
Generating code coverage report, this
may take a moment.
Warning: Unknown: Error occured while
closing statement in Unknown on line 0
Warning: Unknown: Error occured while
closing statement in Unknown on line 0
Warning: Unknown: Error occured while
closing statement in Unknown on line 0
Warning: Unknown: Error occured while
closing statement in Unknown on line 0
Warning: Unknown: Error occured while
closing statement in Unknown on line 0
Warning: Unknown: Error occured while
closing statement in Unknown on line 0
Warning: Unknown: Error occured while
closing statement in Unknown on line 0
Warning: Unknown: Error occured while
closing statement in Unknown on line 0
[workspace] $ /bin/bash -xe
/tmp/hudson1439023061736436000.sh
+ /usr/local/bin/phpcpd --log-pmd ./build/logs/cpd.xml ./trunk phpcpd
1.3.2 by Sebastian Bergmann.
Found 1 exact clones with 6 duplicated
lines in 2 files:
library/Ips/Form/Decorator/SplitInput.php:8-14
library/Ips/Form/Decorator/FeetInches.php:10-16
0.04% duplicated lines out of 16585 total lines of code.
Time: 4 seconds, Memory: 19.50Mb [DRY]
Skipping publisher since build result
is FAILURE Publishing Javadoc [xUnit]
[INFO] - Starting to record. [xUnit]
[WARNING] - Can't create the path
/var/lib/hudson/.hudson/jobs/IPS/workspace/generatedJUnitFiles.
Maybe the directory already exists.
[xUnit] [INFO] - Processing
PHPUnit-3.4 (default) [xUnit] [INFO] -
[PHPUnit-3.4 (default)] - 1 test
report file(s) were found with the
pattern 'build/logs/phpunit.xml'
relative to
'/var/lib/hudson/.hudson/jobs/IPS/workspace'
for the testing framework 'PHPUnit-3.4
(default)'. [xUnit] [INFO] -
Converting
'/var/lib/hudson/.hudson/jobs/IPS/workspace/build/logs/phpunit.xml'
. [xUnit] [INFO] - Stopping recording.
Publishing Clover coverage report...
Publishing Clover XML report...
Publishing Clover coverage results...
Finished: FAILURE
What changed since Tuesday? Try to manually run exactly the same commands that Hudson tries to run from the same directory that Hudson starts it from (usually the jobs workspace directory). Of course with the user account that Hudson is started under.
There are several possibilities. ranging from standard groups for a directory, to permission, or other things outside of Hudson. Was Hudson upgraded? Was a plugin upgraded? Was the OS or php upgraded? Was there a change in the default or user .profile or .env (or the equivalent files)? Does another process accesses the workspace? ......
Once I had the problem that all of the sudden my deployment scripts did not run anymore. The mystery was, that I could still run the script from command line with the Hudson user account. The reason was simple but took a while to uncover. There was a java upgrade from 5 to 6. Both versions were available. After comparing the environment variables, there was a difference in the path. The problem was that the new path was set in the global .profile. But Hudson does not open an interactive shell, therefore the .profile will not be executed. If you have a problem like this, you can put the initialization in the .env file (or whatever the filename is for your system), because this will be run regardless if it is a interactive shell or not. Alternatively you can configure Hudson to set it on master or node/slave level.
if you want a command to not break the 'build' as a failure you have to add #! in front of the command to prevent the flags -xe which produce this behaviour.