mackensen / moodle-hat Goto Github PK

I think I did a composer update in the manifest because of an outdated library, but the lock file is there for a reason and it creates problems with the upstream when vagrant changes it locally. Deleting the vendor/ directory and installing has the same effect.

Sometimes puppet tries to load the eduperson schema before the database is configured:

==> default: Error: LDIF content:
==> default: dn: cn=eduperson,cn=schema,cn=config
==> default: objectClass: olcSchemaConfig
==> default: cn: eduperson
...
==> default: Error message: Command original_ldapadd is missing

The problem with behat is that it takes so long to run that its worthwhile having different output plugins that you can examine whilst a run continues. Since I started using the html output plugin and failure dumps I found it a lot more productive. I think something like that would be a great edition to this!

This is the bash function I use with mdk:

function behat () {
    BEHATDATAROOT=`mdk info -v behat_dataroot`
    BEHATPATH=/Users/danp/www/behat_runs/`date +%Y%m%d_%H%M%S`/
    mkdir $BEHATPATH
    mdk info -v behat_faildump_path -e $BEHATPATH

    vendor/bin/behat --format=moodle_progress,progress,html,failed \
        --out=,$BEHATPATH/progress.txt,$BEHATPATH/status.html,$BEHATPATH/failed.txt \
        --config=$BEHATDATAROOT/behat/behat.yml "$@"
}

I serve that behat_runs directory with apache with listings and can examine it whilst a run is going on.
(Only just getting started with vagrant myself, but hope I could make a pull request at some point :))

The Moodle installation creates the config.php it needs so that we don't need to source it in puppet/modules/moodle/manifests/install.php though we may need it elsewhere.

This change eliminates the need for a github auth token.

For those rare cases where a unit test fails on one but not the other.

We should revert #9 and just make sure that we load the config.php from puppet before running admin/cli/install_database.php as an alternative to admin/cli/install.php. The former expects config.php to exist, and by loading the config from puppet we keep the door open to tweak config settings down the road.

Configure a reasonable location for $CFG->behat_faildump_path.

I'm looking at support for the Filescan tool under development by @aruethe2; it requires a somewhat modern version of nodejs.

There are several issues with unit tests in 2.9:

• en_AU compatibility
• database collation

fb1a7a3 introduced problems with behat tests and permissions. Checks need to be recursive and enforced.

Firefox has compatibility problems at higher versions. Restricting to 28 resolves them.

Server checks:

Installing the optional SOAP extension is useful for web services and some plugins.

See Chrome to force .dev domains to HTTPS via preloaded HSTS; *.dev hosts are going to become troublesome under Chrome.

https://tracker.moodle.org/browse/MDL-57558 added new constants for testing lib_ldap. 3.2 and 3.3.

==> default: Error: php admin/tool/behat/cli/init.php returned 250 instead of one of [0]
==> default: Error: /Stage[main]/Moodle::Behat/Exec[configure_behat]/returns: change from notrun to 0 failed: php admin/tool/behat/cli/init.php returned 250 instead of one of [0]

OS: OS X
Vagrant vers.: 1.8.1

This needs to be explicitly included.

What it says on the tin. Useful for running scheduled tasks. I'm thinking about adding it, but commenting it out by default. I can see use cases for when you wouldn't want it running while you were actively developing a new task.

HQ is migrating to Behat 3+ in MDL-50812. The config handler will need to be rewritten; see Rajesh's notes.

Import filescan-server and start it on provision.

Puppet needs to grab the latest selenium standalone jar file.

Webgrind needs g++ to compile but it's not ensured by default.

Following a full provisioning run there are a couple non-ideal situations:

• Parts of /home/vagrant are owned root:root, which prevents composer from using the oauth token as the vagrant user
• Although there's an ACL for vagrant on /var/www/moodle/htdocs, effective permissions wind up being a no-op so you can't reinitialize behat. Apache doesn't need write so owning everything vagrant:vagrant might fix it

Note that this will require Java 8; this requires the ppa:openjdk-r/ppa repository.

This isn't especially well-documented and it's easy to get into a bad place.

Hadn't seen this before:

PHP Fatal error:  Uncaught exception 'RuntimeException' with message 'The HOME or COMPOSER_HOME environment variable must be set for composer to install correctly'

I don't know why this is a problem now when it wasn't before, but setting COMPOSER_HOME as an environment variable is a trivial fix.

Revealed by #26; see http://stackoverflow.com/questions/26261001/warning-about-http-raw-post-data-being-deprecated for context.

Complete behat runs don't finish. This is the short version:

Error communicating with the remote browser. It may have died.
Build info: version: '2.44.0', revision: '76d78cf', time: '2014-10-23 20:02:37'
System info: host: 'moodlehat', ip: '127.0.1.1', os.name: 'Linux', os.arch: 'amd64', os.version: '3.13.0-30-> generic', java.version: '1.6.0_33'
Driver info: driver.version: EventFiringWebDriver

Rather than cloning the moodle directory for each initial provision it can save time to copy an existing local moodle. Similarly, it can be convenient at times to reprovision an existing machine. In both cases, the admin/cli/install.php command will fail, however, if config.php already exists. By removing any potential config.php first we can insure that the command will run.

This is selfish because the local_ldap tests need it but it seems like a common enough use case.

The README should mention that cron is enabled by default and link to the host to view it.

ghostscript amounts to an undocumented dependency for the PDF annotation features. I've no immediate plans to install unoconv but having gs enables Google Drive integration.

Hi everyone,
After vagrant up and all the setup I try to access http://local.moodle.test/ and I have a 404. http://192.168.50.10/ gave me a 503.

I have this error in my log:

vagrant@moodlehat:/var/www/moodle/htdocs$ sudo cat /var/log/apache2/local.moodle.test_error.log
[Wed Feb 10 23:23:41.415993 2021] [proxy:error] [pid 18879] (111)Connection refused: AH00957: FCGI: attempt to connect to 127.0.0.1:9001 (*) failed
[Wed Feb 10 23:23:41.416180 2021] [proxy_fcgi:error] [pid 18879] [client 192.168.50.1:58848] AH01079: failed to make connection to backend: localhost

Anyone had this problem before?

Thank you in advance for your help

I've run into a scenario where I need HTTPS support.

Ran into provisioning problems while working on #41 and #45.

I haven't done much with xdebug, but I've encountered a bug where performance matters. If xdebug proves helpful I'll consider rolling it in. If there are reasonable alternatives to xdebug I'm open to them.

Install the npm package, install the grunt-cli package globally, and run npm install in the root.

When we re-provision an existing machine, I think we need to drop any existing databases, especially but not only if we are planning to use #12.

More compilation fails with xdebug.max_nesting_level at 256.