Document/improve migration options

[atrauzzi]

I noticed this in the docs: The migrations are supported while working in local environment only.

Might be helpful to detail alternatives so that people can run their migrations. Perhaps there's an opportunity for a special migration task to be included in the library? Then people could trigger or queue the job on deploy.

[shpasser]

The ability to trigger or queue a job on deploy looks to me a little dangerous from security point of view. Anyway I would appreciate if we could discuss the matter further.

As I see it, in order to run the migrations we have to deploy them first and then have something to trigger them. Please describe the way you had in mind and maybe will analyze and implement it.

[shpasser]

I think that Artisan::call('migrate') would do the job, but we need to run it only once and make sure no-one will be able to trigger it again.

[atrauzzi]

Doesn't GAE set a specific header when jobs are run as tasks?

[shpasser]

Looks like a good solution for me. If I understand you correctly, you suggest using a cron job in order to trigger the migrations. Application URLs can be secured for cron, so the security should not be a problem.

The next issue to solve is how to collect the results of the command and show them to the operator / admin. I presume we should be able to collect the results, although it is not something that can be done "straight forward", because Artisan::call('migrate') does not return the output of the command.
One of the possible options for presenting the results could be sending an email to the app admin.

[shpasser]

Last artisan command output can be retrieved using Artisan::output().

[atrauzzi]

The only other thing I would suggest is to ensure that the migrations can be triggered arbitrarily from a build server. Not necessarily directly, but via the gcloud tools running on the build server.

That way people can do deploys and then migrations in one swing.

[shpasser]

After some thinking I'm going to take a different path.
Since GAE supports access 'protected' urls I added the following lines to my app.yaml:

        - url: /artisan
          script: public/index.php
          login: admin

The url is handled by a controller capable of running artisan commands and returning their results. I also added a simple view containing a form with an input field for an artisan command and a textarea for its results.
Let me know if you are interested in trying it out or if you have any other suggestions.

[atrauzzi]

I spent some time thinking about this on the weekend and I think I agree with your approach. I'm guessing this will be much better than trying to slip into the task queue.

Once authenticated, a client can simply hit that endpoint to run commands (like from a build server).

To that end, I think it would be a good idea to either document or provide resources and best/common practices for:

• Authenticating a headless client like a build server
• Issuing authenticated requests (CURL, Jenkins) using the credentials
• Parameters for the endpoint

Even if the above three are a wiki page, linked to from readme.md, I think it would be quite valuable. Many people - especially those getting started - I suspect won't be fully versed in App Engine conventions. And if they're coming from a "pure" PHP/Laravel environment, are almost guaranteed to struggle initially.

[shpasser]

Ok, now it is time to do some work. I'll send updates on my progress.

[atrauzzi]

I'm going to be creating the following for my project. The api prefix is just a convention I'm using, but the task/* part might be nice to encourage.

        - url: /api/task/*
          script: public/index.php
          login: admin

That will result in me having the route /api/task/migrate for triggering my migrations.

[shpasser]

I'm going to push Artisan Console for GAE very soon. Still need to update the documentation.

[shpasser]

The Console is there.

[atrauzzi]

I'll check things out next time I have my hands in this stuff, which should be in the next couple of days.