I'm adding a linter for gosec for golangci-lint and everything is covered except the following:
exec.Command(params[0], params[1:]…)
I know that I can disable this lint but I don't want to do it. Is there a way to fix the code to satisfy this lint?
the error is:
G204: Subprocess launched with function call as argument or cmd arguments ```
Instead of disabling the linter you could exclude the specific line with an annotation;
exec.Command(params[0], params[1:]...) //nolint:gosec
If you want to disable only this check, you can
exec.Command(params[0], params[1:]...) // #nosec G204
Hardcode a command call. There are no other options AFAIS.
Update: starting from version 1.40 you gosec options are customizable, see example config .golangci.example.yml in https://github.com/golangci/golangci-lint repository.
linters-settings:
gosec:
# To select a subset of rules to run.
# Available rules: https://github.com/securego/gosec#available-rules
includes:
- G401
- G306
- G101
# To specify a set of rules to explicitly exclude.
# Available rules: https://github.com/securego/gosec#available-rules
excludes:
- G204
# To specify the configuration of rules.
# The configuration of rules is not fully documented by gosec:
# https://github.com/securego/gosec#configuration
# https://github.com/securego/gosec/blob/569328eade2ccbad4ce2d0f21ee158ab5356a5cf/rules/rulelist.go#L60-L102
config:
G306: "0600"
G101:
pattern: "(?i)example"
ignore_entropy: false
entropy_threshold: "80.0"
per_char_threshold: "3.0"
truncate: "32"
Related
I have a go linter in a .golangci.yml file for my workspace. As of now, I have disabled lints in test files since there are simply too many checks:
run:
tests: false
# rest of run configs ...
issues:
# all run issues
However, I want to enable lint checks only on new test files, or new diffs. Any existing linting errors should be ignored.
I tried modifying the yml file using a new : true parameter under issues:
run:
tests: false
# rest of run configs ...
issues:
new : true
# all run issues
However, the linter still checks all test files for listing, including the previous problems.
I tried switching the order and also replacing new : true with max-same-issues : 0.
I was in particular following this guide: https://golangci-lint.run/usage/configuration/.
It's also worth noting that the SVC is Perforce, not Git.
I'm trying to run build-wrapper around my C code and it ran to completion without error, doing the build as it's supposed to do. However, in the output directory, only build-wrapper-dump.json and build-wrapper.log are created. There is no build-wrapper.json file. My sonar-project.properties file:
# must be unique in a given SonarQube instance
sonar.projectKey=GtiAnalys
#----- Default SonarQube server
sonar.host.url=http://sonarqubedev:9000
# --- optional properties ---
# defaults to project key
#sonar.projectName=My project
# defaults to 'not provided'
#sonar.projectVersion=1.0
# Path is relative to the sonar-project.properties file. Defaults to .
sonar.sources=CSources
# Encoding of the source code. Default is default system encoding
sonar.sourceEncoding=UTF-8
# Properties specific to the C and C++ analyzer:
sonar.cfamily.build-wrapper-output=bw-output
sonar.projectBaseDir=/export/home/binh/GtiAnalys
sonar.working.directory=/export/home/binh/GtiAnalys/sonar
sonar.verbose=true
sonar.language=c
sonar.inclusions-**/*.c,**/*.h
sonar.cxx.file.suffixes=.c
My command is: build-wrapper-linux-x86-64 --out-dir build_wrapper make -f /export/home/binh/GtiAnalys/makefile -C ./CSources clean libGtiAnalys.so
Any ideas? The make command without the build-wrapper works fine. Thanks.
Turns out I don't need this file. Just the build-wrapper-dump.json seems to do the trick.
To improve the structure of my Gitlab CI file I include some specific files, like for example
include:
- '/ci/config/linux.yml'
- '/ci/config/windows.yml'
# ... more includes
To avoid the error-prone redundancy of the path I thought to put it into a variable, like:
variables:
CI_CONFIG_DIR: '/ci/config'
include:
- '${CI_CONFIG_DIR}/linux.yml' # ERROR: "Local file `${CI_CONFIG_DIR}/linux.yml` does not exist!"
- '${CI_CONFIG_DIR}/windows.yml'
# ... more includes
But this does not work. Gitlab CI claims that ${CI_CONFIG_DIR}/linux.yml does not exist, although the documentation says that variables in include paths are allowed, see https://docs.gitlab.com/ee/ci/variables/where_variables_can_be_used.html#gitlab-ciyml-file.
What also didn't work was to include a file /ci/config/main.yml and from that include the specific configurations without paths:
# /ci/config/main.yml
include:
- 'linux.yml' # ERROR: "Local file `linux.yml` does not exist!"
- 'windows.yml'
# ... more includes
How can I make this work or is there an alternative to define the path in only one place without making it too complicated?
This does not seem to be implemented at the moment, and there is an open issue at the moment in the backlog.
Also, with the documentation saying that you could use variables within include sections, those are only for predefined variables.
See if GitLab 14.2 (August 2021) can help:
Use CI/CD variables in include statements in .gitlab-ci.yml
You can now use variables as part of include statements in .gitlab-ci.yml files.
These variables can be instance, group, or project CI/CD variables.
This improvement provides you with more flexibility to define pipelines.
You can copy the same .gitlab-ci.yml file to multiple projects and use variables to alter its behavior.
This allows for less duplication in the .gitlab-ci.yml file and reduces the need for complicated per-project configuration.
See Documentation and Issue.
My project is extending open-source classes from a third-party gem that we don't want to hold to the same coding standards as our own code. Refactoring the gem code isn't a viable option. We just want Rubocop to ignore the copied code.
How can I instruct Rubocop to completely ignore a file or directory?
As per orde's comment with the link to the manual I found .rubocop.yml and added the following:
AllCops:
Exclude:
- 'path/to/excluded/file.rb'
where the path is relative to .rubocop.yml
From rubocop/default.yml:
AllCops:
Exclude:
- 'node_modules/**/*'
- 'vendor/**/*'
Can also consider comments for a single file. Great for ignoring the linter for a quick and dirty temporary task.
# rubocop:disable all
module TempTask
...
end
# rubocop:enable all
For your convenience, here is the .rubocop.yml I frequently used.
See formal explanation of .rubocop.yml here.
AllCops:
Exclude:
- Berksfile
- recipes/basic.rb
- attributes/*.rb
# Customize rules
Metrics/LineLength:
Max: 95
MethodLength:
Max: 35
Metrics/AbcSize:
Enabled: false
BlockLength:
Max: 70
I constantly bump by rubocop errors and warning. Thus I've published this post.
Common Rubocop Errors: Improve Your Ruby Code Quality
When using Rubocop through Visual Studio I could not get the former answers to work.
I eventually noticed that Rubocop was not in fact executing from the root of my project file but from my own root directory and so using:
# Doesn't work :(
AllCops:
Exclude:
- db/schema.rb
was failing because db was not in the same directory that Rubocop was looking for it.
I then changed it to
# Works :)
AllCops:
Exclude:
- */schema.rb
and it works fine. Note there are no quotation marks around the file name.
I'm using a newer version and every time I add Exclude rubocop will hang. Turned out I need to tell how to merge Exclude. This might work for you
require:
- rubocop-rails
inherit_mode:
merge:
- Exclude
AllCops:
Exclude:
- 'node_modules/**/*'
- 'vendor/**/*'
NewCops: disable
I work with a software framework which has a couple of classes with method names containing capital letters (due to C++ wrappers). This is of course not PEP8 and pylint shows the corresponding error C0103. I also added C0111 to the list to ignore the missing docstrings for some methods, like this:
def Configure(self): # pylint: disable=C0103,C0111
It works, however now I get warnings because of the local disablings:
Class: I0011 -> locally disabling C0103
Class: I0011 -> locally disabling C0111
How should I suppress them?
OK, so obviously one has to ignore the ignore-warning explicitly. One can do this in the pylint config file: if you don't have one, simply generate a standard configuration via
pylint --generate-rcfile > pylint.rc
and uncomment the line with disable=... and add I0011 to the list. This suppresses all warnings regarding "locally defined disablings".
The other method is to add the following line to the beginning of a file (or block, whatever), if you don't want to suppress the warning globally:
#pylint: disable=I0011