release 1.1.1

Author: jandelgado

CHANGELOG.md

@@ -1,5 +1,10 @@
 # changelog for gcov2lcov
 
+## 1.1.1 [2024-10-23]
+
+* provide a release package `gcov2lcov-linux-amd64.tar.gz` to be compatible
+  with older `gcov2lcov-action` versions
+
 ## 1.1.0 [2024-10-11]
 
 * use goreleaser for builds and provide additional versions

README.md

@@ -17,20 +17,31 @@ uses some parts of [goveralls](https://github.com/mattn/goveralls).
 
 ## Installation
 
-```
+### Binary download
+
+Download a version for your platform from the [Releases](https://github.com/jandelgado/gcov2lcov/releases) page.
+
+You may have noticed that the file `gcov2lcov-linux-amd64.tar.gz` does not
+follow the naming convention used for other artifacts. This particular file is
+provided for backward compatibility with the `gcov2lcov-action` and can be
+disregarded for general use.
+
+### Compile from source
+
+```text
 $ go install github.com/jandelgado/gcov2lcov@latest
 ```
 
 ## Usage
 
-```
+```text
 Usage of ./gcov2lcov:
   -infile string
-    	go coverage file to read, default: <stdin>
+        go coverage file to read, default: <stdin>
   -outfile string
-    	lcov file to write, default: <stdout>
+        lcov file to write, default: <stdout>
   -use-absolute-source-path
-    	use absolute paths for source file in lcov output, default: false
+        use absolute paths for source file in lcov output, default: false
 ```
 
 ### Example
@@ -42,17 +53,18 @@ gcov2lcov -infile=coverage.out -outfile=coverage.lcov
 
 ### GOROOT
 
-It might be necessary to set the `GOROOT` environment variable properly before calling `gcov2lcov`.
-If you see `cannot find GOROOT directory` warnings like e.g.
+It might be necessary to set the `GOROOT` environment variable properly before
+calling `gcov2lcov`. If you see `cannot find GOROOT directory` warnings like
+e.g.
 
-```
+```text
 022/05/23 16:00:58 warn: go/build: importGo github.com/pashagolub/pgxmock/: exit status 2
 go: cannot find GOROOT directory: /opt/hostedtoolcache/go/1.13.15/x64
 ```
 
 Then call `gcov2lcov` with 
 
-```
+```text
 $ GOROOT=$(go env GOROOT) gcov2lcov -infile=coverage.out -outfile=coverage.lcov
 ```
 
@@ -67,12 +79,15 @@ The following desription is taken from the [geninfo
 manpage](http://ltp.sourceforge.net/coverage/lcov/geninfo.1.php) of the [lcov
 homepage](http://ltp.sourceforge.net/coverage/lcov/):
 
-```
-A tracefile is made up of several human-readable lines of text, divided into sections. If available, a tracefile begins with the testname which is stored in the following format:
+```text
+A tracefile is made up of several human-readable lines of text, divided into
+sections. If available, a tracefile begins with the testname which is stored in
+the following format:
 
 TN:<test name>
 
-For each source file referenced in the .da file, there is a section containing filename and coverage data:
+For each source file referenced in the .da file, there is a section containing
+filename and coverage data:
 
 SF:<absolute path to the source file>
 
@@ -92,31 +107,42 @@ Branch coverage information is stored which one line per branch:
 
 BRDA:<line number>,<block number>,<branch number>,<taken>
 
-Block number and branch number are gcc internal IDs for the branch. Taken is either '-' if the basic block containing the branch was never executed or a number indicating how often that branch was taken.
+Block number and branch number are gcc internal IDs for the branch. Taken is
+either '-' if the basic block containing the branch was never executed or a
+number indicating how often that branch was taken.
 
 Branch coverage summaries are stored in two lines:
 
 BRF:<number of branches found> BRH:<number of branches hit>
 
-Then there is a list of execution counts for each instrumented line (i.e. a line which resulted in executable code):
+Then there is a list of execution counts for each instrumented line (i.e. a
+line which resulted in executable code):
 
 DA:<line number>,<execution count>[,<checksum>]
 
-Note that there may be an optional checksum present for each instrumented line. The current geninfo implementation uses an MD5 hash as checksumming algorithm.
+Note that there may be an optional checksum present for each instrumented line.
+The current geninfo implementation uses an MD5 hash as checksumming algorithm.
 
-At the end of a section, there is a summary about how many lines were found and how many were actually instrumented:
+At the end of a section, there is a summary about how many lines were found and
+how many were actually instrumented:
 
 LH:<number of lines with a non-zero execution count> LF:<number of instrumented lines>
 
 Each sections ends with:
 
 end_of_record
 
-In addition to the main source code file there are sections for all #included files which also contain executable code.
+In addition to the main source code file there are sections for all #included
+files which also contain executable code.
 
-Note that the absolute path of a source file is generated by interpreting the contents of the respective .bb file (see gcov (1) for more information on this file type). Relative filenames are prefixed with the directory in which the .bb file is found.
+Note that the absolute path of a source file is generated by interpreting the
+contents of the respective .bb file (see gcov (1) for more information on this
+file type). Relative filenames are prefixed with the directory in which the .bb
+file is found.
 
-Note also that symbolic links to the .bb file will be resolved so that the actual file path is used instead of the path to a link. This approach is necessary for the mechanism to work with the /proc/gcov files.
+Note also that symbolic links to the .bb file will be resolved so that the
+actual file path is used instead of the path to a link. This approach is
+necessary for the mechanism to work with the /proc/gcov files.
 
 ```