How to run tflint rules all at one for a specific provider? - testing

I installed the tflint plugin but when I run tflint on the root module I get nothing. When I specify a rule with --enable-rule then I get some warnings. How can I run the ruleset of azure or aws all at once?

when it comes to azure you can install the plugin by adding a config to .tflint.hcl and running tflint --init:
plugin "azurerm" {
enabled = true
version = "0.14.0"
source = "github.com/terraform-linters/tflint-ruleset-azurerm"
}
If you want to add a new rule to this ruleset, you can use the generator
$ go run ./rules/generator
You can find the list of rules available for the tflint-ruleset-azurerm Here

Related

How to provide an HttpClient to ktor server from the outside to facilitate mocking external services?

I am trying to provide an HttpClient from the outside to my ktor server so that I can mock external services and write tests, however I get this exception when I run my test:
Please make sure that you use unique name for the plugin and don't install it twice. Conflicting application plugin is already installed with the same key as `Compression`
io.ktor.server.application.DuplicatePluginException: Please make sure that you use unique name for the plugin and don't install it twice. Conflicting application plugin is already installed with the same key as `Compression`
at app//io.ktor.server.application.ApplicationPluginKt.install(ApplicationPlugin.kt:112)
at app//com.example.plugins.HTTPKt.configureHTTP(HTTP.kt:13)
at app//com.example.ApplicationKt.module(Application.kt:14)
at app//com.example.ApplicationTest$expected to work$1$1.invoke(ApplicationTest.kt:39)
at app//com.example.ApplicationTest$expected to work$1$1.invoke(ApplicationTest.kt:38)
and thats a bit unexpected to me because I am not applying the Compression plugin twice as far as I can tell. If I run the server normally and manually call my endpoint with curl then it works as expected. What am I doing wrong?
I added a runnable sample project here with a failing test.
sample project
official ktor-documentation-sample project.
The problem is that you have the application.conf file and by default, the testApplication function tries to load modules which are enumerated there. Since you also explicitly load them in the application {} block the DuplicatePluginException occurs. To solve your problem you can explicitly load an empty configuration instead of the default one:
// ...
application {
module(client)
}
environment {
config = MapApplicationConfig()
}
// ...

How to debug neovim lsp custom command

I am attempting to get the volar vue language server to work in place of vetur for neovim's native lsp.
Using both lspconfig and lspinstall I was able to create a working custom install for sumneko_lua (unrelated but had to manually build due to some issues with the built-in :LspInstall lua). Below is that code duplicated and modified for an attempt at using this new vue server:
local vue_config = require'lspinstall/util'.extract_config('vuels')
vue_config.default_config.cmd = {'node', './node_modules/vscode-vue-languageservice/out/index.js', '--stdio'}
require'lspinstall/servers'.newvue = vim.tbl_extend('error', vue_config, {
install_script = [[
! test -f package.json && npm init -y --scope=lspinstall || true
npm install vscode-vue-languageservice#latest
]],
uninstall_script = nil
})
Running :LspInstall newvue installs properly, however :LspInfo shows this language server is attached to the buffer (of a .vue file) but not active. I believe the issue is with this path: ./node_modules/vscode-vue-languageservice/out/index.js. It exists, but may not be the correct entry point? The default vue ls simply has vls as the command because it provides a binary. Am I missing something in this package? I have yet to come across another language server without a single binary to pick out.
Thanks!
Can you try an absolute path to the out.js file? In my pretty elaborate config for a custom Volar install I'm using something just /home/myuser/dev/volar/packages/server/out/index.js (where the volar folder is just the whole volar cloned github repo). My full config is here
I don't think you can use relative paths like you did. I know you're assuming that the "./node_modules" means "workspace directory" but it's hard to tell in which directory nvim-lspconfig opens up those executables.
I have yet to come across another language server without a single binary to pick out.
Volar also provides a binary, it's volar-server (after running npm i -g #volar/server), it's just with a custom install (ie. alongside the real volar) you can't use it, because I assume you want to use your local install with custom code.
As for more indepth debugging/logging, you can check ~/.cache/nvim/lsp.log to see why the language server dies in detail.

SAUCE_CONFIG_PATH is not working for me in testcafe-browser-provider-saucelabs

I am trying to use testcafe-browser-provider-saucelabs.
My tests can successfully connect to SauceLabs and run there, but testcafe creates a unique sauceconnect tunnel, whereas I need to use a shared tunnel. Also, screenResolution is not being picked up from sauceLabsConfig.json file.
I have saucelabs credentials set as environment variables.
I am launching tests using these commands:
export SAUCE_JOB="Regression Job"
export SAUCE_BUILD="Build 1"
export SAUCE_CONFIG_PATH="./sauceLabsConfig.json"
testcafe saucelabs:chrome tests/
I created a sauce config JSON file:
{
"parentTunnel": "PARENT_TUNNEL",
"tunnelIdentifier": "qa",
"screenResolution": "1920x1080"
}
Why is my SAUCE_CONFIG_PATH variable not working?
At present, not all SauceLabs options are supported for the 'testcafe-browser-provider-saucelabs'. For example, the tunnelIdentifier option is not supported. I've created an issue in the browser provider repository. Track it be informed about the progress.
Note that this issue seems to be fixed, per this pull request:
https://github.com/DevExpress/saucelabs-connector/pull/33
...and integrated in to testcafe 1.14.0:
https://github.com/DevExpress/testcafe/tree/v1.14.0

Vue CLI 3 service worker fails to register out of box

I built my app using Vue CLI3 with PWA. When I build for production the service worker fails to register.
I then decided to check if it was something I did or Vue CLI 3 out the box. I built a brand new app, built it and deployed it to AWS s3 with cloudfront. Even the brand new app without any changes fails to register the service worker with error: "The script has an unsupported MIME type ('text/plain')." and "Error during service worker registration: DOMException"
I've tried quite a few things other than listed below that google search results suggested but I end up with the same error.
I tried using the vue.config.js to load a custom worker in which I just copied the contents of the one that vue produces in a build.
pwa: {
workboxPluginMode: 'InjectManifest',
workboxOptions: {
swSrc: 'public/service-worker.js'
},
themeColor: '#ffffff'
}
I have tried loading it from index.html also.
If I host it locally it registers without any issues
The file does get created and it's accessible from the console but for some odd reason unknown to me it does not want to register at all.
Has anyone had this problem before and how did you resolve this?
Hosted on AWS s3 & cloudfront with HTTPS enabled and using the default AWS certificates for testing.
$ vue --version
3.9.3
$ node --version
v12.7.0
$ npm --version
6.10.0
UPDATE
I found that when I upload to S3 using aws cli sync it changes all .js files content-type
Once I resolve this I will update my question again.

Apache Directory LDAP API - getting up and running

When I try and run a test using the Apache LDAP API, I am getting the following error. I set up a Maven project , and my pom.xml has many dependencies for the Apache Directory server and API artifacts. My code (which I copied and pasted an example, just to get up and running, so that I can explore) all builds fine. However, when I run it (as a Junit Test), I get the following....
Can anyone help me? maybe even just provide an example of where the Apache LDAP API is being used successfully, and maybe give me the pom.xml with the correct dependencies also? (The apche LDAP API documentation seems to be out of date).
I am currently starting the test using the embedded Apache Directory server, using the following...
#RunWith(FrameworkRunner.class)
#CreateLdapServer(transports =
{
#CreateTransport(protocol = "LDAP") ,
#CreateTransport(protocol = "LDAPS") })
// disable changelog, for more info see DIRSERVER-1528
#CreateDS(enableChangeLog = false, name = "PasswordPolicyTest")
public class PasswordPolicyIT extends AbstractLdapTestUnit
{ .......etc }
So, therefore, an alternative approach, is that if I tailor some of the tests to just connect to a local Directory Server instance that I have running on my machine. I assume that this would stop the error messages that I am getting below..Again, if anyone could provide a code snippet there, it would be useful..
Many Thanks
> 2013-06-20 16:05:10 ERROR FrameworkRunner:287 - Problem locating LDIF
> file in schema repository Multiple copies of resource named
> 'schema/ou=schema/cn=apachemeta/ou=matchingrules/m-oid=1.3.6.1.4.1.18060.0.4.0.1.3.ldif'
> located on classpath at urls
> jar:file:/Users/rk/.m2/repository/org/apache/directory/api/api-ldap-client-all/1.0.0-M17/api-ldap-client-all-1.0.0-M17.jar!/schema/ou%3dschema/cn%3dapachemeta/ou%3dmatchingrules/m-oid%3d1.3.6.1.4.1.18060.0.4.0.1.3.ldif
> jar:file:/Users/rk/.m2/repository/org/apache/directory/shared/shared-ldap-schema-data/1.0.0-M7/shared-ldap-schema-data-1.0.0-M7.jar!/schema/ou%3dschema/cn%3dapachemeta/ou%3dmatchingrules/m-oid%3d1.3.6.1.4.1.18060.0.4.0.1.3.ldif
> jar:file:/Users/rk/.m2/repository/org/apache/directory/server/apacheds-all/2.0.0-M12/apacheds-all-2.0.0-M12.jar!/schema/ou%3dschema/cn%3dapachemeta/ou%3dmatchingrules/m-oid%3d1.3.6.1.4.1.18060.0.4.0.1.3.ldif
You need to exclude the shared-ldap-schema-data dependency from apacheds-all. Take a look at this comment