Codeception environment configuration not working - configuration

Codeception: Configuration file(s) placed in tests/_envs are not working. I am trying to run my acceptance tests in multiple environments (ex. dev, qa, staging, prod). So I have setup dev.yml, qa.yml, staging.yml and prod.yml files under tests/_env directory. Each of those separate environment I am overriding the WebDriver - url.
file - dev.yml
modules:
config:
WebDriver:
url: 'dev.mysite.local'
Then when I try to run the acceptance test suite using one of the environment, ex
./vendor/bin/codecept run acceptance --env dev
It doesn’t pull in the dev configuration, but instead uses the default configuration from acceptance.suite.yml file. What am I doing wrong?

There is a bug in the codeception/configuration.php file where a wrong regular expression has been used, which prevents .yml file from being loaded. However, dist.yml files loads just fine. They have already pushed a change for this bug.
In case you don't have this changeset, you can manually change it on your codeception/configuration.php file or simply use the dist.yml extension.
Wrong regex:
$envFiles = Finder::create()
->files()
->name('*{.dist}.yml')
->in($path)
->depth('< 1');
Correction:
$envFiles = Finder::create()
->files()
->name('*.yml')
->in($path)
->depth('< 1');
Thanks to sjableka for the answer posted on the Codeception repo.

Related

Github Action how to deal with standalone config file

We are using Github Action to deploy our code. On push, the source code will be pushed and we were able to build the code and deploy successfully if the config file is also tracked by the repository. However, we are encountering a problem with a config file in .gitignore.
Our app has different versions, controlled by this config file, and also this file is different from testing to production. Therefore, this file is standalone and not tracked by the git repository. However, for Github actions to build the project correctly, this file is necessary and has to be placed on a certain path of the project, e.g., /configs/env_configs.json.
This seems like a very common use case but I find very little information in Github action's document.
Is there a good way to work this out?

Vue.js is detected on this page. Devtools inspection is not available because it's in production mode or explicitly disabled by the author

I'm trying to enable vue-devtools in Google Chrome. But I cannot enable it. I'm using vue.js inside the Laravel application.
My server runs using php artisan serve command.
I was seeing the error message in this question's title and this solution worked for me:
Add Vue.config.devtools = true to the file where you create the Vue instance (main.js for me).
Note that, as mentioned in this answer, you need to put the Vue.config.devtools = true line before you create your store in order for the Vuex part of the devtools to work. If you're creating your Vuex store in a separate file (e.g. store.js), you may need to have the Vue.config.devtools = true line in both your main.js file as well as the store.js file.
Below is what the changes looked like in my project:
If the page uses a production/minified build of Vue.js, devtools
inspection is disabled by default so the Vue pane won't show up.
To make it work for pages opened via file:// protocol, you need to
check "Allow access to file URLs" for this extension in Chrome's
extension management panel.
I had to restart the chrome, and it worked :-)
If your using CDN; make sure your not using a production (minified) build of the library.
Use: https://unpkg.com/vue#2.4.4/dist/vue.js
Instead of: https://unpkg.com/vue#2.4.4/dist/vue.min.js
You might need to do Ctrl+Alt+I for it to show up the first time. (Source)
Updated Aug 2022
So apparently as #kissu said, the answer below causes the released code to be an unoptimized one. This might be different than what you want if you want to check production code while being able to check Vue Dev Tools.
Just be aware of it. Unless you don't mind checking the released code in an unoptimized bundle, then the following script is fine. If you don't like the Vue.config.devtools value being static, it might be time to consider env variables or something similar.
Here's how to setup Environtment Variables in Vue
Alternative answer for Vue CLI 3.x
Besides what #NathanWailes has said, this is an alternative which allows the Dev Tools to be available through scripts instead of writing it in your main Vue entry (which is usually main.js or index.js).
You can do this by simply adding this script to package.json
scripts: {
"start:dev": "vue-cli-service build --mode=development"
}
Explanation
This was because Vue.config.devtools are set to false by default in production mode as said by this GitHub Issue. But this has a work around, simply by using --mode=development flag provided in the documentation.
Then you can run using npm run start:dev and check the file in your dist/ folder! ;)
You may use the dev version of vue.js. For example get it here: https://unpkg.com/vue#2.3.2
When using Laravel just make sure you run the proper webpack for your environment for development . Running
npm run watch
should build Vue with debug mode on. Using
npm run production
minifies Vue for production. This will save you having to remember to toggle the debug mode when building for production.
For me Installing latest Vue dev tools - link and enabling 'Allow access to file URLs' in extension settings resolved the issue.
make sure you're running a non-production build of Vue.js. https://github.com/vuejs/vue-devtools/issues/62
Just add into vue.config.js:
module.exports = {
configureWebpack: {
devtool: 'source-map'
}
}
delete package-lock.json, node_modules, run npm i and VueJS Devtool will be working
you could try to set environment variable NODE_ENV to 'development'
(e.g. set NODE_ENV=development on Windows or export NODE_ENV="development" under Linux)
before launching Vue dev server.
In my case for Laravel 9 fresh installation, I forgot to run sail npm run dev.
If you're using Vite you can configure your environment directory via shared options. If you change that and have NODE_ENV set to production you'll receive this message when trying to inspect your app.

Azure AppService deploy.cmd using the wrong file

I am trying to configure continuous deployment to a test server on Azure. The app is an ASP.Net application, but in this case that shouldn't really matter.
My build process (team city) produces a folder that has everything needed to deploy (minus some connection string info). If you point IIS at that directory it works great. If you FTP that directory up to Azure it also works.
I am tracking each of these builds in git and pushing them up to Github. So I am trying to use Azure deployment option to deploy from github. Everything is in git. The /bin folder included.
Kudu shouldn't need to do anything but a pull from git and copy all the files to wwwroot.
So I've set my .deployment file to be this:
[config]
project = .
Every time I do that, though, the deployment gives me the message:
Using cached version of deployment script (command: 'azure -y --no-dot-deployment -r "D:\home\site\repository" -o "D:\home\site\deployments\tools" --aspWAP "D:\home\site\repository\MyProj.csproj" --no-solution').
And it runs some generic autogenerated deploy.cmd.
If I delete the deploy.cmd from the cache, it regenerates some generic one.
And, most importantly, in doing all this, the WRONG ASSEMBLY IS BEING DEPLOYED!!
My app depends on System.Web.Helpers.dll. The correct version of this DLL is in github. I've verified this multiple times.
Kudu, however, is grabbing an OLDER one from NuGet and deploying that. And, of course, I get the dreaded YSOD error about not being able to load that file.
What do I need to do to make Kudu just copy the files from my github repository to wwwroot and nothing else?
I wound up getting it to deploy by hand editing the autogenerated deploy.cmd file that lives at \home\site\deployments\tools\deploy.cmd in kudu.
I commented out the 2 autogenerated lines of:
:: 1. Restore NuGet packages
:: 2. Build to the temporary path
(commented out all the code underneath them, too)
And then hand-edited the 3rd section to run kudu sync from the DEPLOYMENT_SOURCE instead of the temp file like this:
:: 3. KuduSync
IF /I "%IN_PLACE_DEPLOYMENT%" NEQ "1" (
call :ExecuteCmd "%KUDU_SYNC_CMD%" -v 50 -f "%DEPLOYMENT_SOURCE%" -t "%DEPLOYMENT_TARGET%" -n "%NEXT_MANIFEST_PATH%" -p "%PREVIOUS_MANIFEST_PATH%" -i ".git;.hg;.deployment;deploy.cmd"
IF !ERRORLEVEL! NEQ 0 goto error
)

Polymer web component tester: multiple sauce configurations?

I'm using SauceLabs for my web component tests through the 'sauce' plugin in the web component tester. I'd like to use this plugin with different configurations depending which branch is being built on my CI.
I.E.: Latest chrome only on dev branches, and the whole battery of browsers/OS on master/staging branches (with deploy env.)
How can I achieve that?
Copy a template file before you start wct
// Test master branch
$ cp wct.conf.master.json wct.conf.json && wct
// Test feature branch
$ cp wct.conf.feature.json wct.conf.json && wct
The best way to do so for now remains the cp/mv method as stated in the official answer, but in web-component-tester#v6.0.0-prerelease.8, they included back the --config option (see this commit), so we'll be able to specify which config file to use at runtime without modifying any file.

Jenkins MSTest Issue

I have configured Jenkins as the CI for a project which is using Mercurial as the source control management. I'm using MSTest plugin in Jenkins to see the test results and I have written a bat command to generate test result file
del results.trx
mstest /testcontainer:Example\TestProject1\bin\debug\TestProject2.dll /resultsfile:results.trx
it gives an error in console saying File "Example\TestProject1\bin\debug\TestProject2.dll" not found"
when every build happens a folder is created under %WORKSPACE% having a new name (SYSTEM_My_Computer_Name 2011-06-08 13_04_11). In that the test dll is in a directory called out. How can I get path to that dll, because the directory name is changed for every build?
It is working fine when I used a absolute url like "c:\Example\TestProject1\bin\debug\TestProject2.dll"
How can we refer the newly built dll ?
Do I need to add test dll file in to the repository ?
Jenkins run bat files with %WORKSPACE% as the current directory.
As the error message indicates, the relative path to the test container is wrong. I can think of two things that can be the issue here:
The folder structure under %WORKSPACE% does not match your relative path. Adding a cd by its own in the bat file will reveal on the build output where this is. You can also use the links in the Jenkins web ui to browse the workspace.
You are building a different msbuild target in Jenkins, for example release. Then \bin\debug might not exist.
The folder "SYSTEM_My_Computer_Name 2011-06-08 13_04_11" is not created by Jenkins during the build, but it is created by the mstest when it is running the test. The root folder when the mstest is invoked is the workspace root folder, so the testcontainer file should be specify from the workspace root.
For example, say if the dll file is under C:\jenkins\jobs\\workspace\TestProject1\bin\debug\TestProject2.dll(assume your jenkins is installed under c:\jenkins).
The command should be (relative to the workspace root folder):
mstest /testcontainer:TestProject1\bin\debug\TestProject2.dll /resultsfile:results.trx