Please see the attached image (courtesy HgInit's Mercurial tutorial).
What does it mean by
--- a
+++ b
## -1,4 +1,4 ##
--- a/guac - the outgoing file (the first version to be compared), in this case, since it is about two versions of the same file, a virtual path prefix a/ is prefixed, even when it doesn't exist actually
+++ b/guac - the incoming file (the second version to be compared)
## -1,4 +1,4 ## - the outgoing and incoming line ranges, meaning in this case -1,4 the outgoing/original/first version refers to line 1 and 4 following lines, while +1,4 the incoming/new/second version refers to the same range. Meaning that you'll end up with the same amount of lines (after taking out those with - prefix and putting in those with + prefix, in the rest of the diff chunk)
Related
I have been trying to get this done for two days now. I have had different error to deal with. I am Using an M1 Apple Chip Mac pro and Xcode 13.4 and it has been difficult to get Sonarqube running. I finally found a docker image which is M1 specific and I have been able to get Sonarqube running locally.
My current challenge is having the test result sent to the Sonarqube project.
I have tried several method which includes
xcrun xccov view YourPathToThisFile/*.xccovreport --json
This script is not working even though I wanted an xml format.
Is there a better way to have the code coverage report sent to sonarqube. I have Sonarqube running but the test result and coverage is not showing. Sonarqube page currently says "The main branch has no lines of code."
NB: I am running Sonarqube with Docker
Below is my Sonarqube properties file.
#
# Swift SonarQube Plugin - Enables analysis of Swift and Objective-C projects into SonarQube.
# Copyright © 2015 Backelite (${email})
#
# This program is free software: you can redistribute it and/or modify
# it under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation, either version 3 of the License, or
# (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU Lesser General Public License for more details.
#
# You should have received a copy of the GNU Lesser General Public License
# along with this program. If not, see <http://www.gnu.org/licenses/>.
#
# Sonar Server details
sonar.host.url=http://localhost:9000/
sonar.login=782a04fee8bfc7ae181f04bbd13734eb89e5580c
# sonar.password=admin
# Project Details
sonar.projectKey=tinggios
sonar.projectName=TinggIOSApp
sonar.projectDescription=This is TinggiOS
# Comment if you have a project with mixed ObjC / Swift
sonar.language=swift
sonar.projectKey=tinggios
sonar.qualitygate.wait=true
# Path to source directories
# sonar.sources=SonarDemo,SonarDemoTests,SonarDemoUITests
sonar.sources=.
# Exclude directories
sonar.test.inclusions=**/*Test*/**
sonar.test.inclusions=*.swift
sonar.exclusions=**/*.xml,Pods/**/*,Reports/**/*
# sonar.inclusions=*.swift
# Path to test directories (comment if no test)
sonar.tests=TinggIOS/Core/Tests/CoreTests,TinggIOS/Home/Tests/HomeTests,TinggIOS/OnboardingUITest
# Destination Simulator to run surefire
# As string expected in destination argument of xcodebuild command
# Example = sonar.swift.simulator=platform=iOS Simulator,name=iPhone 6,OS=9.2
# sonar.swift.simulator=platform=iOS Simulator,name=iPhone 7,OS=12.0
sonar.swift.simulator=platform=iOS Simulator,name=iPhone 11,OS=15
# Xcode project configuration (.xcodeproj)
# and use the later to specify which project(s) to include in the analysis (comma separated list)
# Specify either xcodeproj or xcodeproj + xcworkspace
sonar.swift.project=TinggIOS/TinggIOS.xcodeproj
sonar.swift.workspace=TinggIOS/TinggIOS.xcworkspace
sonar.language=swift
sonar.c.file.suffixes=-
sonar.cpp.file.suffixes=-
sonar.objc.file.suffixes=-
# Specify your appname.
# This will be something like "myApp"
# Use when basename is different from targeted scheme.
# Or when slather fails with 'No product binary found'
sonar.swift.appName=TinggIOS
# Scheme to build your application
sonar.swift.appScheme=TinggIOS
# Configuration to use for your scheme. if you do not specify that the default will be Debug
sonar.swift.appConfiguration=Debug
##########################
# Optional configuration #
##########################
# Encoding of the source code
sonar.sourceEncoding=UTF-8
# SCM
# sonar.scm.enabled=true
# sonar.scm.url=scm:git:http://xxx
# JUnit report generated by run-sonar.sh is stored in sonar-reports/TEST-report.xml
# Change it only if you generate the file on your own
# The XML files have to be prefixed by TEST- otherwise they are not processed
sonar.junit.reportsPath=sonar-reports/TEST-report.xml
# Cobertura report generated by run-sonar.sh is stored in sonar-reports/coverage-swift.xml
# Change it only if you generate the file on your own
sonar.swift.coverage.reportPattern=sonar-reports/coverage-swift*.xml
#sonar.coverageReportPaths=sonarqube-generic-coverage.xml
#sonar.swift.coverage.reportPattern=sonar-reports/cobertura.xml
# OCLint report generated by run-sonar.sh is stored in sonar-reports/oclint.xml
# Change it only if you generate the file on your own
sonar.swift.swiftlint.report=sonar-reports/*swiftlint.txt
# Change it only if you generate the file on your own
sonar.swift.tailor.report=sonar-reports/*tailor.txt
# Paths to exclude from coverage report (surefire, 3rd party libraries etc.)
# sonar.swift.excludedPathsFromCoverage=pattern1,pattern2
# sonar.swift.excludedPathsFromCoverage=.*Tests.*,
##########################
# Tailor configuration #
##########################
# Tailor configuration
# -l,--max-line-length=<0-999> maximum Line length (in characters)
# --list-files display Swift source files to be analyzed
# --max-class-length=<0-999> maximum Class length (in lines)
# --max-closure-length=<0-999> maximum Closure length (in lines)
# --max-file-length=<0-999> maximum File length (in lines)
# --max-function-length=<0-999> maximum Function length (in lines)
# --max-name-length=<0-999> maximum Identifier name length (in characters)
# --max-severity=<error|warning (default)> maximum severity
# --max-struct-length=<0-999> maximum Struct length (in lines)
# --min-name-length=<1-999> minimum Identifier name length (in characters)
sonar.swift.tailor.config=--no-color --max-line-length=100 --max-file-length=500 --max-name-length=40 --max-name-length=40 --min-name-length=4
In my foo_git.bb:
SRC_URI = "git://github.com/foo/foo.git;branch=main;protocol=https;name=${BPN};destsuffix=git \
git://github.com/foo2/foo2;branch=main;protocol=https;name=${FOO2};destsuffix=${FOO2} \
file://0001-Modify-A_value.patch\
"
I want my patch to apply to foo2 but it always applied to foo. ( patch failed )
I found patchdir appended after the patch can work.
ex:
file://0001-Modify-A_value.patch;patchdir=${WORKDIR}/${FOO2_path}
From the OE manual
Patch files will be copied to ${S}/patches and then applied to source from within the source directory, ${S}. so for your use case to work your patch filenames should include their base repo name.
For example let’s say 0001-Modify-A_value.patch is as follows:
diff --git a/my.txt b/my.txt
index fa5cb9a..59369cc 100644
--- a/my.txt
+++ b/my.txt
## -1 +1 ##
-I am foo who lives in bar
+I am bar who lives in foo
To make it apply to foo2 you must modify it as follows:
--- foo2/my.txt
+++ foo2/my.txt
## -1 +1 ##
-I am foo who lives in bar
+I am bar who lives in foo
Bitbake uses Quilt for patching so for errors and so on look at its manual.
Another handy tool by bitbake to help you further is the devtool which is designed to handle tasks like updating a recipe or patching it.
I have the following patch referenced in my spec file. It works with proxy hardcoded but I need to use a variable, which fails. Can anyone please advise on the correct syntax?
diff --git .yarnrc.yml .yarnrc.yml
index 6cc7483..b560e95 100644
--- .yarnrc.yml
+++ .yarnrc.yml
## -1,4 +1,8 ##
enableTelemetry: false
+enableStrictSsl: false
+networkConcurrency: 1
+httpProxy: %{http_proxy}
+httpsProxy: %{https_proxy}
nodeLinker: pnp
UPDATE:
Comments don't seem to format well so throwing latest incarnation taking onboard reply from Aaron here, which also fails to build (in jenkins). Edited patch verified in jenkins console.
From spec file
%prep
%setup -n %{name}-%{version}
sed -i 's|httpProxy:.*|httpProxy: "'$http_proxy'"|g' %{PATCH0}
sed -i 's|httpsProxy:.*|httpsProxy: "'$https_proxy'"|g' %{PATCH0}
%patch0
Revised patch
diff --git .yarnrc.yml .yarnrc.yml
index 6cc7483..7c3f6df 100644
--- .yarnrc.yml
+++ .yarnrc.yml
## -1,4 +1,9 ##
enableTelemetry: false
+enableStrictSsl: false
+networkConcurrency: 1
+httpProxy: ******
+httpsProxy: ******
nodeLinker: pnp
RPM isn't going to replace those lines in the diff file; you will need some script or something to do that for you before the build. Or you can put it in as part of your %build macro like sed -i -e "s/_HTTP_PROXY_/%{http_proxy}/g" .yarnrc.yml where the yml file you have in your source has a placeholder _HTTP_PROXY_ ...
I am subscribed to multiple GitHub repository channels and I am constantly seeing stuff like this:
File Changes
M .circleci/config.yml (2)
M .gitignore (2)
M doc/_static/style.css (9)
M doc/conf.py (4)
M doc/documentation.rst (2)
R examples/visualization/plot_make_report.py (8)
M mne/report.py (48)
M mne/tests/test_report.py (32)
What do the Ms and Rs mean when describing these file changes?
This list is a summary of the changes that were done in a specific commit. These letters indicate what happened to the file next to them:
M - modified
A - added
D - deleted
R - renamed
and there are a few more.
These shortcuts are taken from the output for the git status --short command which you can read about more in its documentation.
Recently, I am learning diff and patch. I created two files, file a with content abc and file b with content def. Then I used diff -u a b > p and patch < p, it behaved correctly, as shown in the following:
[joe#joe-pc c]$ ls
a b
[joe#joe-pc c]$ more a
abc
[joe#joe-pc c]$ more b
def
[joe#joe-pc c]$ diff -u a b > p
[joe#joe-pc c]$ more p
--- a 2018-12-20 22:56:33.865661540 +0800
+++ b 2018-12-20 22:54:15.241516269 +0800
## -1 +1 ##
-abc
+def
[joe#joe-pc c]$ patch < p
patching file a
[joe#joe-pc c]$ more a
def
[joe#joe-pc c]$ more b
def
[joe#joe-pc c]$ ls
a b p
[joe#joe-pc c]$
But if I changed the filename from a to ab, something strange happened. The patch < p command told me that
patching file b
Reversed (or previously applied) patch detected! Assume -R? [n]
[joe#joe-pc c]$ ls
ab b
[joe#joe-pc c]$ more ab
abc
[joe#joe-pc c]$ more b
def
[joe#joe-pc c]$ diff -u ab b > p
[joe#joe-pc c]$ more p
--- ab 2018-12-20 22:57:29.767980973 +0800
+++ b 2018-12-20 22:54:15.241516269 +0800
## -1 +1 ##
-abc
+def
[joe#joe-pc c]$ patch < p
patching file b
Reversed (or previously applied) patch detected! Assume -R? [n] ^C
[joe#joe-pc c]$
The file contents are the same, but why in the second situation the patch cannot find the right file ab to be patched?
The above operations were performed in a Linux machine with bash shell.
Thanks in advance.
It's a feature of GNU patch. As you haven't specific the file to patch, it has to be deduced from the input somehow. Basically, if you don't specify paths (only base names), it assumes that it has to patch the file with a shorter name, unless --posix command line argument is passed or POSIXLY_CORRECT environment variable is set:
patch --posix <p
# or
POSIXLY_CORRECT=1 patch <p
In your case, between a and b the first one is chosen correctly, but for ab and b the second one is chosen as patch target (as patching file b line suggests), but patching fails, hence the error.
You can also fix this behavior by either specifying patch target explicitly:
patch ab <p
Digging into docs
GNU patch uses the following logic (see patch's manual, "10.6 Multiple Patches in a File" section):
First, patch takes an ordered list of candidate file names as follows:
If the header is that of a context diff, patch takes the old and new file names in the header. ...
...
Then patch selects a file name from the candidate list as follows:
If some of the named files exist, patch selects the first name if conforming to POSIX, and the best name otherwise.
For "uniform context format" the "old" file is mentioned after --- (a or ab in your case), and the "new" file is mentioned after +++ (b in your case).
If both files exist and patch is not configured to be "confirming to POSIX" (e.g. by setting POSIXLY_CORRECT environment variable or --posix command line argument, see "10.12 patch and the POSIX Standard" section of the manual), then patch will choose "the best" name out of two. "Name" here includes full path obtain from the patch file (doesn't matter in your case). Details are specific later:
To determine the best of a nonempty list of file names, patch first takes all the names with the fewest path name components; of those, it then takes all the names with the shortest basename; of those, it then takes all the shortest names; finally, it takes the first remaining name.
"Name component" here is basically a folder/file name (e.g. /foo/bar/baz has three of them), "basename" is just the name of the file (baz).
So, if names are a (old) and b (new) and both files exist, there is no "best name", so the first one is patched.
But if names are ab (old) and b (new) and both files exist, then b is "better", so the tool tries to patch it and fails.
I have no idea why this behavior was made the default.