I've just installed Codeception (using Composer) with Symfony 2.3 in a Vagrant box running on Windows 8.1. When I try to run tests using bin/codecept run or bin/codecept run acceptance, I get this error:
Log path is not defined by key "paths: _logs"
I do have a tests/_logs folder present. The codeception.yml is posted below. The weird thing is, when I change the name of _logs folder to anything else (for example 'log'), with a corresponding change to the "log" parameter in codeception.yml, I still get the same error message that refers to "_logs". Even if I delete the _logs directory and/or remove the reference to it in codeception.yml, I get the same error message. I tried reinstalling Codeception, restarting Vagrant, rebooting the computer, and still getting the same error.
My two teammates are able to run tests with the same code and with the same Vagrant box with no problems. The difference is that one of them is using a Mac OS and the other one is using a PC with Linux. Could this problem be related to Windows?
Here's my codeception.yml file:
paths:
tests: tests
log: tests/_logs
data: tests/_data
helpers: tests/_helpers
settings:
bootstrap: _bootstrap.php
suite_class: \PHPUnit_Framework_TestSuite
colors: true
memory_limit: 1024M
log: true
modules:
config:
Db:
dsn: 'mysql:dbname=s2_at_test;host=127.0.0.1'
user: 's2_at_test'
password: #hidden#
dump: tests/_data/dump.sql
populate: true
cleanup: true
Related
Ever since I've upgraded my Mac to Monteray, I've been having issues with Vagrant.
Initially, I use to see a vBoxManage error on terminal when running vagrant up. I posted a question on this on SO previously, see here for details.
Today, I uninstalled VirtualBox again (removed VirtualBox VMs folder and moved application to trash) and reinstalled VirtualBox 6.1.3 for OS X hosts` (link here).
I then ran vagrant up on terminal and it successfully compiled:
After seeing the famous green teddy, I tried going to vvv.test but, the page doesn't load. I've tried accessing URLs of sites that have been provisioned before, but they too do not load.
I've also ran vagrant up --debug, and nothing concerning was seen.
My Vagrant version is 2.2.19
Unsure what steps to take next?
Edit:
Steps taken:
Have ran vagrant up --provision to provision sites in config.yml file (config.yml file can be seen below)
Have tried to access website-dev.test, page doesn't load
Have tried to access vvv.test, page doesn't load
Have ran vagrant reload --provision and repeated steps 2 and 3, but same results
Have ran vagrant halt and vagrant up and repeated steps 2 and 3, but same results
I don't believe there's an issue in my config.yml file, as before Monteray update, everything was working fine (and I've made no changes to my yml file since). But, to cover all scenario's, here is my config.yml file:
sites:
website-dev:
skip_provisioning: false
description: ""
hosts:
- website-dev.test
custom:
wpconfig_constants:
WP_DEBUG: true
WP_DEBUG_LOG: true
WP_DISABLE_FATAL_ERROR_HANDLER: true
wordpress-trunk:
skip_provisioning: true
description: "An svn based WP Core trunk dev setup, useful for contributor days, Trac tickets, patches"
repo: https://github.com/Varying-Vagrant-Vagrants/custom-site-template-develop.git
hosts:
- trunk.wordpress.test
wordpress-meta-environment:
skip_provisioning: true
description: "An environment useful for contributions to the WordPress meta team."
repo: https://github.com/WordPress/meta-environment.git
hosts:
- wp-meta.test
custom:
provision_site:
"buddypressorg.test": true
"jobs.wordpressnet.test": true
"wordcamp.test": true
"wordpressorg.test": true
"wordpresstv.test": true
utilities:
core:
- tls-ca
- phpmyadmin
vm_config:
memory: 1600
cores: 2
general:
db_backup: true
db_restore: true
db_share_type: false
vagrant-plugins:
disksize: 10GB
In regards to vagrant ssh, I'm unsure on what steps I would need to take to get vvv.test to start working again here, can't see anything on the docs for this also?
Thanks to guidance from #Tinxuanna, I've managed to solve the issue (finally!).
For anyone else having similar issues, here's what I did:
Access the /etc/hosts folder
Find file called hosts and open it in a text editor.
Remove the IP addresses related to vagrant (I kept a backup of the original file just in case)
After saving hosts file the IP addresses removed, I ran vagrant up --provision
I then ran vagrant up
Then accessed vvv.test
You're done!
After trying the solutions provided by others, I determined that the problem on my machine was a wrong ip range in Vagrantfile. To solve this:
Edit Vagrantfile
Change IP defaults['private_network_ip'] = '192.168.56.4' to different range
Save it and run vagrant up --provision
If Freddy's solution doesn't work, then give this a try.
I'm trying to use Concourse to grab a dockerfile defintion from a git repository, do some work, build the docker image, and push the new image to Artifactory. See below for the pipeline definition. At this time I have all stages up to the artifactory stage (the one that pushes to Artifactory) working. The artifactory stage exits with error with the following output:
waiting for docker to come up...
sha256:c6039bfb6ac572503c8d97f42b6a419b94139f37876ad331d03cb7c3e8811ff2
The push refers to repository [artifactory.server.com:2077/base/golang/alpine]
a4ab5bf94afd: Preparing
unauthorized: The client does not have permission to push to the repository.
This would seem straight-forward as an Artifactory permissions issue, except that I've tested locally with the docker cli and am able to push using the same user/pass as specified within destination_username and destination_password. I double checked the credentials to make sure I'm using the same ones and find that I am.
Question #1: is there any other known cause for getting this error? I've scoured the resource github page without finding anything. Any ideas why I may be getting the permissions error?
Without having an answer to the above question, I'd really like to dig deeper into troubleshooting the problem. To do so I use fly hijack to get a shell in the corresponding container. I notice that docker is installed on the container, so next step I think would be to do a docker import on the tarball for the image I'm trying to push and then perform a docker push to push it to the repo. When attempting to run the import I get the error:
Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is
the docker daemon running?
Question #2: Why can't I use docker commands from within the container? Perhaps this has something to do with the issue I'm seeing with pushing to repo when running the pipeline (I don't think so)? Is it because the container isn't running with privilege? I thought that the privileged argument would be supplied in the resource type definition, but if not, how can I run with privilege?
resources:
- name: image-repo
type: git
source:
branch: master
private_key: ((private_key))
uri: ssh://git#git-server/repo.git
- name: artifactory
type: docker-image
source:
repository: artifactory.server.com:2077/((repo))
tag: latest
username: ((destination_username))
password: ((destination_password))
jobs:
- name: update-image
plan:
- get: image-repo
- task: do-stuff
file: image-repo/scripts/do-stuff.yml
vars:
repository-directory: ((repo))
- task: build-image
privileged: true
file: image-repo/scripts/build-image.yml
- put: artifactory
params:
import_file: image/image.tar
Arghhhh. Found after much troubleshooting that the destination_password wasn't being picked up properly due to special characters and a lack of quotes. Fixed the issue by properly setting the password within yaml file being included with the --load-vars flag.
I am trying to deploy my app via MUP ,everything works fine except when I run command mup deploy. In browser website loads but it does not shows the latest changes I have made. Build files has all changes that I have made.I am using Amazon EC2 for server.
Edit:
In MUP logs it shows that server has started on port 80. I also checked the build file it has latest code but somehow server is not rendering in browser.I am not sure its issue of MUP Or meteor build or amazon EC2 server.
Since I'm having the exact same problem, I can clarify the question.
I'm using Mup build 1.2.8/latest on Windows 10, Meteor v1.4.4.2/latest, deploying to Ubuntu 14.04 on Digital Ocean.
Doing "mup.cmd deploy" builds the bundle, pushes it to the server, starts the app and verifies the deployment, all successfully. The meteor logs as shown by "mup.cmd logs" shows the app started successfully (other than the Kadira warning which should be fixed in the newly deployed version). Browsing to my app doesn't show any of my recent changes (they do show up when running locally). It seems as if the updated container isn't the one running. I've tried starting, stopping and removing the Docker container to no avail.
For reference, here is the mup.js file I'm using (with the names changed to protect the guilty). This file worked to deploy fine 6 weeks ago.
module.exports = {
servers: {
one: {
host: '1.2.3.4',
username: 'Ron',
pem: '/cygwin64/home/Ron/.ssh/id_rsa',
}
},
meteor: {
name: 'MyApp',
path: '../',
servers: {
one: {}
},
buildOptions: {
serverOnly: true,
debug: true,
cleanAfterBuild: true,
buildLocation: '../../output'
},
env: {
// TODO: Change to your app's url
// If you are using ssl, it needs to start with https://
ROOT_URL: 'https://MyApp.com',
MONGO_URL: 'mongodb://localhost/meteor'
},
docker: {
// change to 'kadirahq/meteord' if your app is not using Meteor 1.4
image: 'abernix/meteord:base'
},
// This is the maximum time in seconds it will wait
// for your app to start
// Add 30 seconds if the server has 512mb of ram
// And 30 more if you have binary npm dependencies.
deployCheckWaitTime: 60,
ssl: {
autogenerate: {
email: 'email#example.com',
domains: 'MyApp.com, www.MyApp.com'
}
},
// Show progress bar while uploading bundle to server
// You might need to disable it on CI servers
enableUploadProgressBar: true
},
mongo: {
port: 27017,
version: '3.4.1',
servers: {
one: {}
}
}
};
EDIT::
I deleted all of the containers and images except mongo, ran "mup setup" and "mup deploy" again with exactly the same results, old version is running. So the problem seems to be with the meteor build portion of mup.
EDIT 2::
I found at least 1 of the problems. I have the buildLocation set to a relative path. At some point Mup changes the current directory which causes multiple copies of the buildLocation to be used. In my case the output of the Meteor build command (the new files) were in one and Mup was deploying to the server from another one that happened to contain the old files. I changed buildLocation to an absolute path and the new version is being deployed. Yeah! But wait, even though Mup says the verification worked, my app never runs and the container keeps restarting. Looking out the logs I suspect that the problem is with the line below. Somehow the path has a backslash in it. I'm not sure where this is coming from.
[192.241.229.15]npm ERR! enoent ENOENT: no such file or directory,
chmod
'/bundle/bundle/programs/server/npm/node_modules/sshpk/bin\sshpk-conv'
SOLUTION:: Thanks to Parth Mahida I was inspired to remove the /opt/MyApp directory on the server, as well as removing and reinstalling the sshpk NPM package on my build machine then redid Mup setup and Mup deploy and everything worked again. No idea how the sshpk package became corrupt, but at this point I don't care.
I have a Symfony 2.4.4 site with simple Codeception (2.1.7) acceptance tests setup. When running the acceptance tests I get the following error:
[Codeception\Exception\ConfigurationException]
AcceptanceTester class doesn't exist in suite folder.
Run the 'build' command to generate it
The AcceptanceTester class does exist in the tests/acceptance directory. If I run a build I get the following error:
[Codeception\Exception\ConfigurationException]
Configuration file could not be found.
Run `bootstrap` to initialize Codeception.
The codeception.yml file does exist and contains the following:
actor: Tester
paths:
tests: tests
log: tests/_output
data: tests/_data
helpers: tests/_support
settings:
bootstrap: _bootstrap.php
colors: false
memory_limit: 1024M
coverage:
enabled: true
remote: true
include:
- app/*
exclude:
- app/cache/*
include:
...
modules:
config:
Db:
dsn: ''
user: ''
password: ''
dump: tests/_data/dump.sql
If I run a bootstrap it confirms this:
Project is already initialized in '.'
acceptance.suite.yml contains:
class_name: AcceptanceTester
modules:
enabled:
- AcceptanceHelper
Any suggestions?
AcceptanceTester.php file should be in tests/_support directory.
Run codecept build to regenerate Tester files.
You have no modules enabled acceptance.suite.yml.
You have to enable one of Symfony2, PhpBrowser and WebDriver.
Your site uses an old version of Symfony and it can cause issues for Codeception if Symfony2 module is used, so I recommend to test it using PhpBrowser or WebDriver.
I believe, you need to run command codecept bootstrap.
I had this problem, and I realise that I ran the codecept bootstrap but the vendor and the tests folders were in a wrong directory.
I followed this video and it helped me.
Recently I've been working on improveing my vagrant enviroment and I've stumbled upon Running the Symfony application on Vagrant without NFS below 100ms blog post.
I've moved the vendor dir outside the VM shared directory, as suggested, by createing /tmp/app/vendor dir inside the VM and setting
export COMPOSER_VENDOR_DIR=/tmp/app/vendor
export COMPOSER_BIN_DIR=/tmp/app/bin
export SF2_ENV=vagrant
enviroment variables before running composer install.
Now, with vendors correctly installed to another path, I've modified the app/autoload.php file to detect if the app is running inside the VM by looking for the SF2_ENV enviroment variable:
if (array_key_exists('SF2_ENV', $_SERVER) && $_SERVER['SF2_ENV'] === 'vagrant') {
// vagrant enviroment detected
$loader = require sys_get_temp_dir().'/app/vendor/autoload.php';
} else {
// default
$loader = require __DIR__.'/../vendor/autoload.php';
}
This worked fine for one project, however on another project I kept getting the
PHP Fatal error: Cannot redeclare class Gedmo\Loggable\Entity\MappedSuperclass\AbstractLogEntry in /var/www/public_html/vendor/gedmo/doctrine-extensions/lib/Gedmo/Loggable/Entity/MappedSuperclass/AbstractLogEntry.php on line 13
error when trying to initialize the app cache php app/console cache:clear -e=prod.
Why was this happening?
Note: I've anwsered myself, as this is a Q&A style question (a note to my future self).
I am posting this as a reminder to my future self or anyone else interested. The problem was becouse in the second project I used Gedmo library and in my config.yml I defined:
doctrine:
orm:
entity_managers:
default:
filters:
softdeleteable:
class: Gedmo\SoftDeleteable\Filter\SoftDeleteableFilter
enabled: true
mappings:
gedmo_translatable:
type: annotation
prefix: Gedmo\Translatable\Entity
dir: "%kernel.root_dir%/../vendor/gedmo/doctrine-extensions/lib/Gedmo/Translatable/Entity"
alias: GedmoTranslatable
is_bundle: false
So, the problem was clearly the %kernel.root_dir% part, which was hardcoded.
Solution
I've simply changed it to %vendor_dir% and defined this parameter in my parameters.yml - for production as vendor_dir: '%kernel.root_dir%/../vendor' and for local (dev) as vendor_dir: /tmp/app/vendor.
I already have problem with symfony2 project on Vagrant. But I resolve this without change location of /vendor directory.
Just disable the nfs share and locate your projects directly on /var/www
you can use this on vagrantFile :
config.vm.synced_folder '.', '/vagrant', disabled: true
Work with your Vagrant as like you work with a remote server...
What happening when you deploying in production environment your autoload.php file ? it's not very useful to change this only for dev environment (I don't speak only for this file but general idea).