I've recently updated rubocop for a gem I'm working on. When I open a ruby file in the project using VSCode, I get the following warning:
The following cops were added to RuboCop, but are not configured. Please set Enabled to either `true` or `false` in your `.rubocop.yml` file:
- Lint/RaiseException (0.81)
- Lint/StructNewOverride (0.81)
- Style/HashEachMethods (0.80)
- Style/HashTransformKeys (0.80)
- Style/HashTransformValues (0.80)
For more information: https://docs.rubocop.org/en/latest/versioning/
Here is my .rubocop.yml file:
Metrics/MethodLength:
Max: 20
Layout/LineLength:
Max: 100
AllCops:
Exclude:
- 'spec/**/*'
When I visit the url in the warning it mentions adding a NewCops setting like so:
Metrics/MethodLength:
Max: 20
Layout/LineLength:
Max: 100
AllCops:
NewCops: enable
Exclude:
- 'spec/**/*'
However, I'm getting this new warning:
Warning: AllCops does not support NewCops parameter.
Supported parameters are:
- RubyInterpreters
- Include
- Exclude
- DefaultFormatter
- DisplayCopNames
- DisplayStyleGuide
- StyleGuideBaseURL
- ExtraDetails
- StyleGuideCopsOnly
- EnabledByDefault
- DisabledByDefault
- UseCache
- MaxFilesInCache
- CacheRootDirectory
- AllowSymlinksInCacheRootDirectory
- TargetRubyVersion
The following cops were added to RuboCop, but are not configured. Please set Enabled to either `true` or `false` in your `.rubocop.yml` file:
- Lint/RaiseException (0.81)
- Lint/StructNewOverride (0.81)
- Style/HashEachMethods (0.80)
- Style/HashTransformKeys (0.80)
- Style/HashTransformValues (0.80)
For more information: https://docs.rubocop.org/en/latest/versioning/
The warning instructs me to enable each of these new cops individually but the docs seem to have an easier solution that doesn't work. What am I doing wrong here?
If you are using VS code ruby-rubocop version here is a simple fix for you ->
Configure extension settings -> Select Supress Rubocop Warnings , it is helpful if you share rubocop.yml file in the repository.
I have the same issue here. The NewCops parameter inside AllCops is not recognized so there is only one way to do it which is by disabling or enabling each cop alone like so:
Lint/RaiseException:
Enabled: false
Lint/StructNewOverride:
Enabled: false
Style/HashEachMethods:
Enabled: false
Style/HashTransformKeys:
Enabled: false
Style/HashTransformValues:
Enabled: false
Hope this was helpful.
The NewCops parameter is not supported yet. However, it will be supported in the next release of Rubocop. Next to this parameter, you will also be able to use --enable-pending-cops and --disable-pending-cops command-line options.
For the moment EL Zakariae's solution is the only way to remove this warning.
You can find the corresponding pull request here.
Related
Goal🚩: I want to add Xcode Target Build Settings - Active Compilation Conditions via XcodeGen.
Is there any soultion to achieve this?
I've tried to add this code into project.yml file but didn't work.
targets:
...
configs:
Debug:
SWIFT_ACTIVE_COMPILATION_CONDITIONS: DEBUG
PreRelease:
SWIFT_ACTIVE_COMPILATION_CONDITIONS: PRERELEASE
Release:
SWIFT_ACTIVE_COMPILATION_CONDITIONS: RELEASE
And my desired result is this image.
enter image description here
I want to use a github action matrix for different build types, but there's one case of the matrix that I'm not interested in supporting. How do I stop this case from running but still get the build to marked successfully.
In this particular case I want to build Windows and Ubuntu, 32bit and 64bit but I'm not interested in supporting 32bit on Ubuntu. So my matrix would be:
strategy:
fail-fast: false
matrix:
os: [windows-latest, ubuntu-latest]
platform: ['x64', 'x86']
My current solution is to stop each action running by adding an if expression:
- name: Build Native
if: ${{ ! (matrix.os == 'ubuntu-18.04' && matrix.platform == 'x86') }}
While this works okay, I feel there ought to be a more elegant way of solving this. Can anyone help make my yaml script more beautiful?
Perhaps the strategy.matrix.exclude directive is suitable?
From the documentation:
You can remove a specific configurations defined in the build matrix
using the exclude option. Using exclude removes a job defined by the
build matrix.
So in your case, probably something like this:
strategy:
matrix:
os: [windows-latest, ubuntu-latest]
platform: ['x64', 'x86']
exclude:
- os: ubuntu-latest
platform: x86
There are situations where one wants to include or exclude specific matrix coordinates so as not to run some of them, yet (stretching the question a bit) also still want the job to run for a couple of these coordinates, so as to track the evolution of it across commits, while not blocking the whole process.
In that situation, continue-on-error at the job level, combined with matrix include and exclude is very useful:
Prevents a workflow run from failing when a job fails. Set to true to allow a workflow run to pass when this job fails.
This is similar to GitLab CI's allow_failure, although at time of writing GitHub Actions UI only has two states (red failed and green passed) whereas GitLab introduces a third one (orange warning) in that case.
Here is a real-life workflow example:
jobs:
linux:
continue-on-error: ${{ matrix.experimental }}
strategy:
fail-fast: false
matrix:
os:
- ubuntu-20.04
container:
- 'ruby:2.0'
- 'ruby:2.1'
- 'ruby:2.2'
- 'ruby:2.3'
- 'ruby:2.4'
- 'ruby:2.5'
- 'ruby:2.6'
- 'ruby:2.7'
- 'ruby:3.0'
- 'ruby:2.1-alpine'
- 'ruby:2.2-alpine'
- 'ruby:2.3-alpine'
- 'ruby:2.4-alpine'
- 'ruby:2.5-alpine'
- 'ruby:2.6-alpine'
- 'ruby:2.7-alpine'
- 'jruby:9.2-jdk'
experimental:
- false
include:
- os: ubuntu-20.04
container: 'ruby:3.0.0-preview2'
experimental: true
- os: ubuntu-20.04
container: 'ruby:3.0.0-preview2-alpine'
experimental: true
When using conda env export it is possible to remove the build information with --no-build:
...
dependencies:
- _libgcc_mutex=0.1=main
- attrs=19.3.0=py_0
- backcall=0.1.0=py37_0
- beautifulsoup4=4.8.2=py37_0
- biopython=1.76=py37h7b6447c_0
- blas=1.0=mkl
- bleach=3.1.0=py37_0
...
and with --no-build
dependencies:
- _libgcc_mutex=0.1
- attrs=19.3.0
- backcall=0.1.0
- beautifulsoup4=4.8.2
- biopython=1.76
- blas=1.0
- bleach=3.1.0
- bzip2=1.0.8
- ca-certificates=2020.1.1
Could you explain in detail what exactly is this build information? The compiler and its version? What else is in there?
The build information is a hash of the variant keys in the recipe. Quoting the docs:
The takeaway message is that hashes will appear when binary compatibility matters, but not when it doesn't.
and
As of conda-build 3.1.0, this hashing scheme has been simplified. A hash will be added if all of these are true for any dependency:
Package is an explicit dependency in build, host, or run deps.
Package has a matching entry in conda_build_config.yaml which is a pin to a specific version, not a lower bound.
That package is not ignored by ignore_version.
OR
Package uses {{ compiler() }} Jinja2 function.
The documentation is here: https://docs.conda.io/projects/conda-build/en/latest/resources/variants.html#differentiating-packages-built-with-different-variants There's also a blog post (that I can't find now) with some more information.
I have enabled the
network:
session_affinity: true
in my app.yaml but it doesn't work neither it's shown enabled when viewing the configuration by going to App Engine > Versions > Config > View.
Here is what I get there:
runtime: java
api_version: '1.0'
env: flexible
threadsafe: true
handlers:
- url: /.*
script: 'this field is required, but ignored'
automatic_scaling:
min_num_instances: 2
max_num_instances: 20
cpu_utilization:
target_utilization: 0.5
network: {}
resources:
cpu: 1
memory_gb: 4
disk_size_gb: 10
I'm using Spring Boot 2.1 btw.
Session affinity is a Beta feature. In order to use this feature you need to deploy with the beta command.
gcloud beta app deploy
After the deployment completes, you should see the below line in your config view.
network:
session_affinity: true
This is not a beta feature anymore, it's now available in mainstream gcloud but bugged, as explained here:
https://issuetracker.google.com/issues/154647126
For some reason, deploying does not display the parameter as set (in App Engine > Versions > Display config for a version) and it's not working for some people, I can confirm as I'm affected by the issue myself.
This bug is fixed in gcloud v356.0.0
Run gcloud components update to upgrade to the latest version.
Reference: https://issuetracker.google.com/issues/154647126?pli=1
I've got a project structured thusly:
- proj/
- subproj1/
- stack.yaml
- subproj1.cabal
- ...
- subproj2/
- stack.yaml
- pkg1/
- ...
- pkg2/
- ...
- ...
And my subproj1/stack.yaml file contains this:
packages:
- .
- location: ../subproj2
subdirs:
- pkg1
- pkg2
extra-dep: true
I'm noticing inconsistent build behavior, when running "stack build" from within the subproj1/ directory. And I'm wondering if I have set up my project structure in an inherently unstable way. Would it, for instance, be more stable to use a single stack.yaml file, located in the proj/ directory?
Yes, unfortunately there are some known issues with this setup - https://github.com/commercialhaskell/stack/issues/3130 . Hopefully will be fixed at some point! One way to work around this is to set your STACK_YAML environment variable, so that stack invocations will ignore current directory.