I am using dotnet core 2+, but the question is likely much more generic.
My CI pipeline currently looks like this:
dotnet build -c Release
dotnet test
dotnet public -c Release --no-build
For the test step, it uses the default Debug configuration, therefore it also has to build the app using Debug config.
Therefore, I was wondering, whether there is any advantage in running tests using Debug rather than Release or should i just simply add dotnet test -c Release?
I believe it's possible to choose by comparing of the differences between "Debug" and "Release".
In Release mode: there are compiler's optimizations. Compiler does some low-level improvements. This leads to original code can be changed significantly in some places. (some variables and methods calls can be optimized in a non obvious way).
In Debug mode: code is not optimized, and along with final assemblies compiler produces .pdb files with are used for a step by step debugging.
As a conclusion, for tests, is better to use Release mode:
It is lighter than Debug (.pdb files are not needed).
It is faster that Debug (due to compiler's optimizations, .pdb files are not generated).
Tests are run against prod like environment.
P.S. Along with that keep an eye on preprocessor directives and config transformation if they are presented, and depend on build configuration.
Do not use Debug mode if you are not going to debug your tests. Sometimes, people need debugging the app through the tests or even debugging the test itslef. If this is not the case, go with Release mode, it is lighter.
Related
I've started a CUDA application in the new CLion 2020.1 version. Although I can compile and run it, I am not able to debug it, not even the host code. Specifically, debug does not stop at breakpoints, even though I am running the debug build. I'm not encountering this issue with running a regular C project in CLion 2020.1. I don't receive any error message of any kind. Here is my CMakeLists.txt file:
# Setup the CUDA compiler
set(CMAKE_CUDA_COMPILER /usr/local/cuda-10.2/bin/nvcc)
# Setup the host compiler
set(CMAKE_CUDA_HOST_COMPILER /usr/bin/g++-8)
# CMAKE minimum required version
cmake_minimum_required(VERSION 3.16)
project(PageRank_GPU CUDA)
set(CMAKE_CUDA_STANDARD 14)
add_executable(PageRank_GPU main.cu graph.cu graph.cuh vertex.cuh error.cuh parser.cu parser.cuh)
set_target_properties(
PageRank_GPU
PROPERTIES
CUDA_SEPARABLE_COMPILATION ON)
Reporting that the issue has disappeared after playing around in the project settings a bit. Specifically, under Build, Execution, Deployment then Toolchain, I set the C and C++ compilers to gcc-8 and g++-8 respectively (even though I am specifying the compiler in the CMakeLists.txt file) and under CMake, I set the toolchain to "Default" (the one I just modified) instead of "Use Default". After doing that, the debugger stops at breakpoints and I am able to step through my code. I don't understand what happened because, even after reverting the changes, I cannot make the problem re-appear.
There seem to be two approaches for invoking JUnit tests from the OS command shell:
java junit.textui.TestRunner <class-name>
and
java org.junit.runner.JUnitCore <class-name>
When do we use one versus the other?
Also, are there other ways to invoke Junit tests from the OS command shell?
JUnitCore is an entry point of JUnit - so if you want to run a test programmatically or of from some non-java script, I think, its the way to go for JUnit 4.
TestRunner is something a very old junit 3.x
Notice, that nowadays JUnit 5 is the latest available major release and it has yet another way to run the tests.
The question about different ways of running the tests from command line has been already answered Here so I can't add much to this.
However, I can comment on:
Also, are there other ways to invoke Junit tests from the OS command shell?
Nowadays in regular projects people do not run tests like this, instead they use one of build tools (Maven, Gradle for example) that among other things take care of tests.
So for example if you use maven, you can run mvn test and it will compile everything you need, including source code of tests, will take care about all test dependencies and will run all the tests with the help of build-in surefire plugin.
If you don't want to compile anything (assuming that all the code has been already compiled and all is set, you can use mvn surefire:test)
These build tools are also integrated with CI tools (like Jenkins, etc.) So this is considered to be a solved problem.
So unless you're doing something really different (like writing the IDE UI that should run test selected by user on demand or something) there is no really need to run tests with the options you've mentioned.
We currently use cljsbuild to compile our clojurescript source into the assets used in production, but during development, we use lein-figwheel. Both cljsbuild and figwheel are constantly watching for changes of the source and recompile when necessary.
I was wondering, whether it's possible to use just one tool for both, preferably in the same process.
We're fine with switching tools, especially Figwheel Main. Each file change should just compile:
a js with advanced optimizations to be used in production
live reload the code in the browser as figwheel & figwheel main do it
I found this in the figwheel documentation, but it requires manual work like cleaning targets and running the build on demand with special options.
I recently switched from lein-figwheel to figwheel-main (using Clojure Deps in place of lein). Figwheel-Main is much simpler, easier & better (basically it is "Figwheel 2.0").
Figwheel-Main can be used for both the auto-reloading during development and for compiling a single my-app.js output file for deployment or testing. You can use either :whitespace or :advanced compiler optimization level to get a single static *.js output file. I use :whitespace to generate an output file for standalone testing purposes (in Docker with chrome --headless) or :advanced for the final production build.
As a side benefit, Clojure Deps is better than lein for managing conflicting dependency versions.
I built Chromium from the source code (ninja -C out/Debug chrome) and make sure it works. After I executed:
git pull
gclient sync
ninja -C out/Debug chrome
The build system actually starts to building all the parts of the project again. Is it possible to rebuild only the changed parts of chromium?
Always do release build if you don't want to debug chrome browser.
Use ninja -C out/Release chrome to perform a release build. Debug build takes time in linking.
git pull updates your code and gclient sync syncs or sets the HEAD of the repo to the Last Known Good Revision(LKGR). Hence, no. of changed files plus no. of files which were dependent on that would be recompiled again.
From the windows build instructions it lists this build parameter:
is_component_build = true - this uses more, smaller DLLs, and incremental linking.
Execute:
gn args out/WhateverYouWant
Add
is_component_build = true
to the text file, save it, and close it.
For every build after the first it won't compile any components that you haven't changed.
I am setting up a new Hudson task (on WinXP) for a project which generates javascript files, and performs xslt transformations as part of the build process.
The ant build is failing on the XSL transformations when run from Hudson, but works fine when the same build on the same codebase (ie in Hudson's workspace) is run from the command line.
The failure message is:
line 208: Variable 'screen' is multiply defined in the same scope.
I have tried configuring Hudson to use both ant directly and to use a batch script - both fail in Hudson.
I have tried in Firefox, IE6 and Chrome and have seen the same issue.
Can anyone suggest how we can workaround this problem with Hudson?
Problem solved.
Our build is actually dependent on jdk 1.4.2, and Hudson appears to run using 1.6. When I set Hudson to run as a service, it ran as my local user, which meant that it picked up the 1.4.2 JAVA_HOME environment variable - and therefore worked.
I guess another possible solution is to configure Hudson to use 1.4.2 by default.
I would assume this is not an issue with Hudson directly, as it is with the build script and/or the environment itself.
Is your build script relying on certain environment variables being defined, or worse, the job running from within a certain directory structure (i.e. it works if it's run from under /home/mash/blah but not from under another directory like /tmp)? Is the build script making reference to external files by relative paths?
These are the things I would look into. For environment variables, you can tell Hudson to pass these into Ant. For the other issues, you probably want to change your build script. Check the console output provided by Hudson, and maybe set Ant to print verbose/debug messages to get a better idea about the environment/filepaths.