I'm having trouble with a Jenkins pipeline.
The thing is, it seems one of the steps is running in parallel with another (not intentionally):
I have something like:
...
step("build"){
bat [Visual Basic 6 compile command - vb6.exe file.vbp /outdir my/directory]
if(fileExists("my/directory/output.dll"){
println "SUCCESS"
}else{
error("error")
}
...
}
Ok, the problem is: it checks if the files exist before it's written by the compile command... If I put a sleep 10 before the condition, it always runs OK (for now), but obviously, I don't want to have a sleep command in my pipeline.
I don't know if I can control better the order os execution or if maybe the fault lies in the vb6.exe that creates a thread to write the output and then the main thread returns success before the output being written... does this make sense? Does anyone know how may I solve this problem?
My solution is to make the VB6 compilation step blocking.
This is what I run when working locally on my machine:
cmd /c VB6.exe /make someproject.vbp
And it is also the approach used by the Jenkins Visual Basic 6 plugin (I am the author). See this.
Related
I rewrite a program and just removed a lot of code, by just making it a comment. After doing that and adding some tests, it is impossible to run the program anymore.
when running go build it has no errors at all.
But when running go test i only become some weird output:
$ go test
2020/05/05 19:14:24 open : no such file or directory
exit status 1
FAIL fwew_lib 0.002s
This error occurs, before a single test is even run, so within the test framework itself.
Why is there is no file specified that is not found? Any idea, what caused this error and how to fix it?
This error also occurred on multiple machines with windows and linux. And with go 1.14.2 and go 1.13.7.
To get this error yourself:
Repo: https://github.com/knoxfighter/fwew/tree/library
Branch: library
Just download the branch and run go test
Your fork is missing this line from the parent
texts["dictionary"] = filepath.Join(texts["dataDir"], "dictionary.txt")
link
But your fork still has this line which depends on the one mentioned above
Version.DictBuild = SHA1Hash(texts["dictionary"])
link
And so the SHA1Hash "fatals" out since you're essentially passing it an empty string.
link
I'm very new to SGX and wanted to start with something simple. Fortunately, I found this very basic tutorial. Unfortunately, as simple as it is, I can't get it to work. The code executes, but there are errors in the output.
[sgx_create_enclavew ..\urts\win\urts.cpp:195] Couldn't open file with CreateFile()
error 0x200f, failed to create enclave.
Buffertests:
Buffer before change: Hello World!
Buffer after change: Hello World!
Stringtests:
Returned Secret:
Saved Secret: My secret string
Load Secret:
Integertests:
secretIntValue first load: 0
saved a 1337 to the enclave.
secretIntValue second load after 1337 was saved: 0
error, failed to destroy enclave.
image of output
the tutorial says:
If you get the error SGX couldn't find the enclave file. The solution is to move the enclave_test_save.signed.dll into the same folder where the app_test_save.exe is located.
which I've tried, but it didn't solve the problem.
when I try to create the enclave using:
sgx_create_enclave(ENCLAVE_FILE, SGX_DEBUG_FLAG, &token, &updated, &eid, NULL);
it returns: SGX_ERROR_ENCLAVE_FILE_ACCESS
could the problem be a result of using a different version of Visual Studio? (The tutorial uses VS 2012, while I'm using VS 2015)
Did you run the application through command prompt or from IDE?
If you are using IDE, You need to change the debugging properties to $(OutDir) from $(ProjecttDir) under Project Properties->Configuration Properties->Debugging->Working Directory.(Both Enclave and Application) Select the Intel(R) SGX Debugger.
Disclaimer: I had the same error although under a different setting (Ubuntu, eclipse) so I am not sure to what extent this will help.
Before initialize_enclave() is called (which in turn calls sgx_create_enclave()), a chdir(absolutePath) command needs to be executed, where absolutePath needs to be the absolute path to where your executable is.
My error was due to a wrong path I used.
Thanks, I solved it. turns out I had to place enclave_test_save.signed.dll in the root folder with the .edl file and not with the .exe file.
This question requires an understanding of both the Window's start command's behavior and a custom gradle ExecTask's handling of it.
Question
Why does start, with an application as a parameter, wait for the application to exit, only when being executed within a gradle ExecTask?
Explanation
From the command line, this works as expected (starts the application and returns, without waiting for the application to exit):
cmd /c myBuildEnvironment.cmd && start "some title for start" devenv.exe my.sln
Pretty simple, it calls a windows batch script to setup the environment and then launches my.sln in Visual Studio. Works just fine, not waiting for Visual Studio to be closed. And, this is what my gradle task is meant to achieve.
The same works "somewhat", using the following gradle ExecTask with start:
/**
* I know that the executable + args is replaced by commandLine. They're
* just there for readability.
*/
task openVsSolution(type: Exec, dependsOn: setupVsSln) {
description 'Opens the VS solution, in the appropriate version of Visual Studio.'
executable 'start'
environment = taskEnv
workingDir '../../src/solution'
args = [vsDevEnv, 'my.sln']
commandLine winCmdPrefix + executable + args
}
Gradle happily reports Build Successful, while Visual Studio remains open.
However, I say "somewhat" because start will actually ignore the executable argument and open my.sln with the default application for it, Microsoft Visual Studio Version Selector. So, after some research, I found that start assumes that the first parameter is the window title, then application, and lastly, the application arguments. So, I tried this:
task openVsSolution(type: Exec, dependsOn: setupVsSln) {
executable 'start'
environment = taskEnv
workingDir '../../src/solution'
args = ['some title for start', vsDevEnv, 'my.sln']
commandLine winCmdPrefix + executable + args
}
Everything works, start used the correct version of Visual Studio's devenv.exe, which varies based on the VC PlatformToolset, but...gradle sits in the background waiting for Visual Studio to close.
Why? How can I achieve all of the desired behavior?
Update
This might be an environmental problem. Apparently, on one dev's machine, the original gradle start task does stay open, as well. So, any invocation of start through gradle waits for it to complete, in a certain environment. The plot thickens...
Gradle is waiting for start to return is my guess, see this post - Run a background job from Gradle. Read also the comment after the answer, this is started from Java so if there is equivalent of & (run in background) for windows, it wouldn't work.
You can also try and wrapping it in a bat file, execute what you want in the bat file in the background then return right away so that gradle would be happy.
Hope this helps.
I am using travis-ci and biicode to build my project who is depending on boost log. But boost log times are longer than 10 min so I get this message:
No output has been received in the last 10 minutes, this potentially indicates a
stalled build or something wrong with the build itself.
The build has been terminated
The build is working correctly, it's just that boost log is really long to compile with limited resources (I tried to compile it on a VM with 1 CPU and 2GB of RAM and it took almost more than 15 min)
I know this is happening because there is not enough verbose going on so I tried the following flags:
>bii cpp:build -- VERBOSE=1
In the CMakeList.txt, set BII_BOOST_VERBOSE ON as mentionnened here
Set BOOST_LOG_COMPILE_FAST_ON as explained here
Using travis_wait
Actually travis_wait seems to be the correct solution but when I put it in my .travis.yml like this
script: travis_wait bii cpp:build
It does actually doesn't output logs like usually and just time out after 20 min. I don't think the actual building is taking place
What is the correct way to handle this problem?
This is a known issue, Boost.Log takes a long time to compile.
You can use travis_wait to call bii cpp:configure, but I'm with you, I need log feedback (No pun intended). However, I have tried that too and leaded to >50min build, which means travis aborts build on free accounts :( Of course my repo does not build Boost.Log only.
Just as a note, here's part of the settings.py file from the boost-biicode repo:
#Boost.Log takes so much time to compile, leads to timeouts on Travis CI
#It was tested on Windows and linux, works 'ok' (Be careful with linking settings)
if args.ci: del packages['examples/boost-log']
I'm currently working on a solution, launching asynchronous builds while printing progress. Check this issue. It will be ready for this week :)
To speed-up your build, try to play with BII_BOOST_BUILD_J variable to set the number of threads you want for building Boost components. Here's an example:
script:
- bii cpp:configure -DBII_BOOST_BUILD_J=4
Be careful, more threads means more RAM needed to compile at a time. Be sure you don't make the travis job VM go out of memory.
I have a Makefile-powered project in Visual Studio 2010 (uses NAnt, in fact, but that's beside the point).
The output of the build process is a .elf file, and I have a separate, non-VStudio debugger which can be run on that .elf file to debug it.
Building works fine, but when I click the 'debug' button (little green triangle), VStudio fails with "Unable to start program 'XXX.elf'. The specified file is an unrecognized or unsupported binary format"
I'm guessing VStudio is just trying to 'run' the .elf as though it were an .exe, and failing.
What I really want VStudio to do is run "my_debugger.exe XXX.elf" when I press the debug button.
I have tried adding a file association with .elf=>my_debugger.exe
I have updated PATHEXT appropriately as well, and run VStudio under those changes.
Still no luck.
Isn't there somewhere in VStudio where you can specify a custom debug command? I thought there was, but can't find it.
I could just have the build process output a .bat file or something I guess, but this seems silly.
As Jim mentioned you can specify which app to start on run in the project settings (Command field). If you place a debugger there you can pass down your executable as an argument to the debugger being launched (Command Arguments field). This way you can launch the debugger which in turn will launch your executable if the debugger expects any commandline arguments.
MinGW on Windows example:
Command: gdb.exe; Command Arguments: Path\ToMyApp\whatever.exe
will start gdb.exe, gdb.exe will open whatever.exe, parse the debug info and wait for debug instructions.
Command: msys.exe; Command Arguments: gdb.exe Path\ToMyApp\whatever.exe
will start msys.exe, msys.exe will execute "gdb.exe Path\ToMyApp\whatever.exe"
Look at the project properties. Do you have a Debug tab which has a Start Action section giving three choices? Those choices would be: ( ) Start project, (x) Start external program: ... ( ) Start browser with URL.
You can also set the command line arguments and working directory.
Cf. How to: Change the Start Action for Application Debugging