Vagrant dev box

[aquilax]

Vagrant provisioning for development box.

1. Requires Vagrant
2. Clone the repository
3. cd [repository_root]/vagrant
4. vagrant up and wait unti the script finishes
5. Login to the dev box using vagrant ssh
6. Run the backend /opt/SOLAS-Match-Backend, ./run_daemon.sh
7. Open http://localhost:8080 on the host machine.

Added .editorconfig for code consistency.

[alanbarrett]

Hi @aquilax,

Sorry I was busy yesterday and today...

Could you provide annotation of the changes in both these files... diff --git a/ui/composer.json b/ui/composer.json diff --git a/ui/composer.lock b/ui/composer.lock

I am worried that we are bringing in versions of code that we have not tested against. I would need the changes in those two files explained. By the way I am not very knowledgeable about composer.

Alan.

[aquilax]

Hi @alanbarrett The composer.lock files are auto-generated by composer and they pinpoint the installed packages to certain commit hash. I'll put my comments in the code.

[alanbarrett]

Thanks. I realise the composer.lock files are autogenerated, but we will end up with different code than is currently tested. rather than reusing the existing composer.lock (in ui directory).

There may be reasons to upgrade the code used, but we would have to test.

Alan.

On 14 November 2016 at 17:27, Evgeniy Vasilev notifications@github.com wrote:

Hi @alanbarrett https://github.com/alanbarrett The composer.lock files are auto-generated by composer and they pinpoint the installed packages to certain commit hash. I'll put my comments in the code.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/TheRosettaFoundation/SOLAS-Match/pull/1252#issuecomment-260401620, or mute the thread https://github.com/notifications/unsubscribe-auth/AAlN_4KXgG1AYzBucQbSr2qgIzdJTpGfks5q-JoNgaJpZM4KwnvI .

[aquilax]

I agree that it's not ideal situation. The reson for the changes is that the current setup is not installable by composer. I can revert those changes but that means that the codebase won't be deployable.

[alanbarrett]

What is reason for this removal? (although I note the lock file has the same version)...

• "repositories": [
• {
• "type": "package",
• "package": {
• "name": "drslump/protobuf-php",
• "version": "0.9.4",
• "type": "git",
• "source": {
• "url": "git://github.com/drslump/Protobuf-PHP.git",
• "type": "git",
• "reference": "master"
• },
• "autoload": {
• "files": ["library/DrSlump/Protobuf.php"]
• }
• }
• }
• ],

Also do you know if the two lighopenid packages are actually the same codebase slightly modified or are they a rewrite?

It seems like your changes make sense but we need to understand the above and also to think out what needs to be tested to verify all is OK.

Also we need then to decide if/when to update the live server (and if not what if we have to do a recovery, what to we recover to).

Alan.

[aquilax]

The reason for removal is that it is redundant, though harmless.

According to the README (https://github.com/formapro-forks/LightOpenID), the depricated repository was added because the official package was not in the package repository, which seems to be fixed now.

Since this is getting out of scope, my suggestion would be to close this pull request for now, and plan how to bring the dependencies up to date one by one so each can be isolated and tested. Good idea may also be to use single composer entry (not separate for api/ui).

[alanbarrett]

Thanks... I think we should stick with the idea of doing a merge of this pull request.

However, before I do that you need to let me know that you have tested that the vagrant branch works. In particular that the new lightopenid/lightopenid functions.

I will also checkout the vagrant branch and redo composer install and then test everything seems OK on test server.

Alan.

[aquilax]

I register and login successfully to the site with e-mail/password.

[alanbarrett]

I have tested the vagrant branch with new composer.json and composer.lock on the test server (done "php composer.phar install" for ui/ and api/).

I also did diffs to understand the new "vendor" changes...

• ui/vendor/slim/slim: seems effectively identical
• ui/vendor/smarty/smarty: v3.1.16 changed to v3.1.30, quite a few changes
• ui/vendor/drslump/protobuf-php: Seems almost fully equivalent (and api/ also)
• ui/vendor/lightopenid: Seems almost fully equivalent
• api/vendor/league/oauth2-server: v3.1.1 changed to v3.1.2, seems almost fully equivalent
• api/vendor/videlalvaro/php-amqplib: Seems identical except for .git

As far as testing of the new "vendor" code, everything seems to work (here are the key tests)...

• Login to using Google (this exercises Google Single Sign on)
• Login to using Yahoo account (this exercises LightOpenID Single Sign on)
• Login using username and password
• Verified Templates still work (including various POSTs)
• Verified Protobufs still work (communication with API layer e.g. creating a Projects and viewing home page)

I will now do the pull to develop.

I will pull develop to master when I next need to do that for other reasons (there is no urgency).

Note, I will not do the ui/ or api/ "php composer.phar install" on the live Trommons server for now as there does not seem to be any urgency and there is a very slight risk.

Alan.