I'm using LCOV as my graphical means of code coverage to tell me how much of my code I've tested, however it's including folders of code which I do not care about and it's making my coverage lower than it should actually be.
Is there a way exclude entire directories where I can ignore a bunch of cpp files which I don't care about? I know about --remove but this doesn't seem to work for this purpose. I want to exclude all folders following this pattern:
Src/GeneralSubSystems/GA/ except for Iterators
Here is the directories I want to ignore
**Src/GeneralSubSystems/GA/Iterators** I want to include this but exclude everything else
Src/GeneralSubSystems/GA/Converters
Src/GeneralSubSystems/GA/Utils
Src/GeneralSubSystems/GA/Models
Src/GeneralSubSystems/GA/Collapse
Src/GeneralSubSystems/GA/Interview
Src/GeneralSubSystems/GA/Misc1
Src/GeneralSubSystems/GA/Misc2
Src/GeneralSubSystems/GA/Misc3
Src/GeneralSubSystems/GA/Misc4
Src/GeneralSubSystems/GA/Misc5
Here is my current usage:
lcov --gcov-tool /usr/bin/gcov --capture --no-checksum --directory /jenkins/workspace/TCONVENGINE-INSTRUMENTED-BUILD/TCONV/Main/targs/Src --directory /jenkins/workspace/TCONVENGINE-INSTRUMENTED-BUILD/TCONV/Main/targs/Component --output-file ${WORKSPACE}/tps_coverage.info
lcov --remove ${WORKSPACE}/tconv_coverage.info '*/ThrdPrty/*' '*/Src/Low/*' '*/Src/TCCP-C/*' '*/Src/Tool/*' '*/zinAttInterviewDisassembler.*' '/usr/*' -o ${WORKSPACE}/tconv_coverage.info
genhtml --prefix /jenkins/workspace/TCONVENGINE-INSTRUMENTED-BUILD/TCONV/Main --title "TCONV Engine Coverage Analysis" --output-directory ${WORKSPACE}/lcov --num-spaces 3 ${WORKSPACE}/tps_coverage.info
Any help or assistance would be much appreciated, thanks in advance everyone
It might help to add two backslashes before * in the remove list.
E.g. instead of
'Src/GeneralSubSystems/GA/Utils/*'
use
'Src/GeneralSubSystems/GA/Utils/\\*'
Related
I am working on a branching strategy in Github Enterprise, using mikepenz/release-changelog-builder-action to generate changelogs when new main versions are created. Changes are merged into a develop branch first, and when the action generates a changelog, it includes all the tags from the develop branch. All we want is to see the changes themselves, grouped by category (feature, fix etc.). Instead we get what you see in the picture. This is a test repo where I pushed one 'bug fix' but as you can see it is very cluttered with unnecessary tags. I have tried to search on Google as well as the action documentation, but either I don't understand it properly or it's not possible. Any help appreciated. This is the default, without a config file. Essentially, I want to remove everything boxed in red.
I figured out a workaround for this. The step that generates the changelog saves it as a .md file. So, I wrote a step that uses bash to take out what I don't want before the file is used to create a release. the lines I don't want start with either a single # with a space after it, ###, or -. Hopefully this is useful to someone.
- name: Remove clutter from changelog
id: trim-changelog
run: |
cat release_changelog.md | grep -e '^# ' -e ^### -e ^- > trimmed_changelog.md
I am trying to create a rpm using mock. https://fedoraproject.org/wiki/Projects/Mock
I am able to build an rpm through source rpm. Now I want to add a patch to this package and I have no idea how to proceed. Can you please let me know how can I go ahead with this? What is the way to modify/patch a package using mock?
The normal approach here is not to use mock to modify your package in any way. Mock is just a way to ensure that your package is built in a clean environment every time (a fresh chroot), and it's not really meant to do more than that.
The normal thing to do, then, would be to put the patch in the spec file for your RPM itself.
This requires two parts — first, the inclusion of the patch file as part of the package, and second, its application.
For the first, list the patch near the top of the spec file, usually right after your Source line (or lines). Each patch gets a number, and the normal convention is to start counting with 0, so if you have just one, that will look like this:
Patch0: packagename-version-terse_patch_description.patch
As with source files, anything up to the last / in that filename is stripped off, so you can use a URL if you want. The patch will need to be in your RPM sources directory (usually, next to the tarball.)
At this point, if you build a source RPM from your modified spec, the resulting src.rpm file will contain this patch file. (Try it — rpm -qlp packagename-ver-rel.src.rpm). But, it won't be applied. To do that, you need to use the %patch macro.
This goes in the %prep section of the specfile, usually right after the %setup macro line. Each %patch macro has a number corresponding to the Patch line in the header, so for your Patch0, add a line like this:
%patch0 -p1 -b .bugfix
Again by convention, patches used in RPM are made built one level up, so -p1 is appropriate. (Conveniently, this will be correct for diffs made with git, too.) And the -b .bugfix bit isn't necessary, but it's customary for debugging, and I guess serves as a sort of inline comment for what this specific patch macro does. (Replace the string "bugfix" with something appropriate to your actual patch.)
I'm working on some code with a partner. Our make files differ slightly courtesy of different build setups. Because of this, so far we have not been tracking this file. However it would be nice to have at least one of ours tracked. The problem is, when that is done and the other person runs hg update, their copy gets update and the code won't compile.
Is there a way to track the file, but have it such that you can update the working directory selectively? Or is there some other way I should deal with this problem?
This is a slight variant of the standard "how do I deal with a config file" question. The standard answer in SVN, Mercurial, and Git is: don't track the file, instead track <file>.example. Then each user copies that over to <file> and tweaks it as needed.
But Makefiles are a bit smarter than config files: they execute code and can include other files. In which case, it starts making sense to track the Makefile normally and have it include another local file if it's present that overrides the default rules. For instance, the following will work with GNU Make:
# pull in any local user tweaks
-include Makefile.local
MQ extension is the best and The Right Way (tm) to do it (not easiest, but...)
Store common part of file in repo, individual personalisation - in own MQ-patches
Is it possible to combine your Makefiles? Then there is not chance of losing your different configurations by not storing them in version control.
For example, you could add a conditional statement based on the username. My username is ryan and this code echos my name, but if it is run on your computer, it probably will echo "not ryan."
all:
if [ `whoami` = "ryan" ]; then echo "ryan"; else echo "not ryan"; fi
We are trying to use geninfo and genhtml (alternative to gcovr, see here) to produce an html page using coverage provided by gcov.
geninfo creates lcov-tracefiles from gcov's *.gcda files
genhtml generates html files from the above tracefiles
However, the end result includes not only our code, but also files from /usr/include.
Does anyone know of a way to exclude these?
I tried looking at the man page but could not find anything http://linux.die.net/man/1/geninfo
If you're just looking to ignore files from /usr/include, a better option is probably "--no-external", which is intended for exactly this purpose.
lcov --no-external -d $(BLD_DIR) --capture -o .coverage.run
You can use the lcov -r option to remove those files you aren't interested in.
lcov -r <input tracefile> /usr/include/\* -o <output tracefile>
I am trying to do "continuous integration" with TeamCity. I would like to label my builds in a incremental way and the GUID provided by the VCS is not as usefull as a simple increasing number. I would like the number to actually match the revision in number in Mercurial.
My state of affairs:
Mercurial info:
I would like the build to be labeled 0.0.12 rather than the GUID.
Would someone be so kind and save me hours of trying to figure this out ?
As Lasse V. Karlsen mentioned those numerical revision numbers are local-clone specific and can be different for each clone. They're really not suitable for versioning -- you could reclone the same repo and get different revision numbers.
At the very least include the node id also creating something like 0.0.12-6ec760554f2b then you still get sortable release artifacts but are still firmly identifying your release.
If you're using numeric tags to tag releases there's a particularly nice option:
% hg log -r tip --template '{latesttag}.{latesttagdistance}'
which, if the most recent tag on that clone was called 1.0.1 and was 84 commits ago gives a value like:
1.0.1.84
Since you can have different heads that are 84 commits away from a tag in different repos you should still probably include the node id like:
% hg log -r tip --template '{latesttag}.{latesttagdistance}-{node|short}'
giving:
1.0.1.84-ec760554f2b
which makes a great version string.
The best and easiest way to see rev. number in TeamCity build number is to use Build Script Interaction with TeamCity. Namely, it has a possibility to set Build Number.
So, add to your project a new very first build step Command Line with following Command Executable
for /f %%i in ('c:\tortoisehg\hg id -n') do echo ##teamcity[buildNumber '%%i']
And you will get the Mercurial revision number as a label for your every build.
Of course you can change the command in quotes to anything you wish.
I believe my answer is way more correct than the accepted one.
EDIT:
Also you can do the same via MSBuild task rather than Command Executable. Have a MSBuild project file with following code, setup TeamCity to run it as first step, and it will alter its global variable buildNumber:
<Message Text="##teamcity[buildNumber '$(CurrentVersion)']" Importance="High" />
Where CurrentVersion is a string containing full version (for example "1.0.56.20931").
hg id produces the hash (6ec760554f2b), hg id -n produces the local revision number (12).
(Note this is an answer purely from the hg side, how you then get that into TeamCity, I don't know, as I've never used it.)
I managed to use it in Teamcity using a workaround:
<Exec Command="hg log -r tip --template {latesttag}.{latesttagdistance} > $(BuildAgentTempDir)\version.txt"/>
<ReadLinesFromFile File="$(BuildAgentTempDir)\version.txt">
<Output TaskParameter="Lines" ItemName="versionInfo"/>
</ReadLinesFromFile>
<TeamCitySetBuildNumber BuildNumber="#(versionInfo)-{build.number}" />
If you see the MSBuild task "TeamCitySetBuildNumber" I'm using the "{build.number}" variable because it substitutes this with what you set in the build number originally. I used %build.vcs.number% in my original settings (in the Web UI) and the result is just what Ry4an wrote above!
Hope it works for you!
When I used to use Subversion I used to do something similar in TeamCity. The format was:
{Major}.{Minor}.{TeamCity Build No.}.{Subversion Revision No.}
This allowed me to look at an assembly and see which build it came from on TeamCity and the revision number from subversion.
I have now moved to Git which has put me in the same situation as you. After playing with various ideas I have come to the conclusion that I don't actually need the revision, the build is good enough. Because TeamCity is such a powerful tool, all you need is the build number, given the build number you can look at the build history and determine the revision from that.
{Major}.{Minor}.{Macro}.{TeamCity Build No.}
Additionally you can get TeamCity to label your repository with the build number allowing you to look up a given build in your source control.
When providing your build number with numeral mercurial revision, you must be aware, that those numbers are clone-specific and can differ from clone to clone.
In our project we had the same issue. We're using TeamCity 7.1.1. We solved it in the following way:
Add Command line build step to your configuration.
Make this build step run first.
In the build step properties select "Run: 'Executable with parameters'"
Add the following text to Command Executable:
for /f %%i in ('hg id -n') do echo ##teamcity[buildNumber '%%i']
Save changes.
You can also use previously generated build number when performing step 3.
Example:
for /f %%i in ('hg id -n') do echo ##teamcity[buildNumber '%system.build.number%.%%i']
You can use this to make build counter present in your build number.
Read this to get more information!
Remember that teamcity compiles configurations build number before build starts and the correct build number will appear only after your build step will finish its job. That's why, in some cases (f.e. inserting your mercurial revision into artifact's name) you should define build number's value in preceding configuration and refer to it.
Example:
%dep.bt82.build.number%
Read this to get more information!