i'm trying to run a php script using the heroku scheduler. What command should i put in after the $ in heroku. I keep getting file not found. I have transferred the file i want to run to heroku but not luck with running it with the scheduler.
The default PHP buildpack on Heroku does not currently have PHP CLI support, so you can only use it to serve web requests via Apache and not for scripts in worker dynos. However, this is possible if you are using a PHP buildpack that does have CLI support.
To test it out, I forked the PHP buildpack, switched out the PHP binary with one that was compiled with CLI support, and put together small demo of running a scheduled PHP job on Heroku. See the project's readme for step-by-step instructions. To use this fork on an existing app, set the buildpack with:
$ heroku config:add BUILDPACK_URL=https://github.com/ryanbrainard/heroku-buildpack-php.git
Note, the release script in my fork sets up the PATH to resolve the php executable in /app/bin/php with just php, unlike the default buildpack that woud require using the absolute path.
How to run a PHP script with Heroku Scheduler?
Testing and setting up the job
With a directory structure and Procfile looking something like this:
├─ Procfile
├─ web/
├── (your webfiles)
├─ worker/
└── myscript.php
Procfile:
web: vendor/bin/heroku-php-apache2 web/
worker: php worker/myscript.php
Then you can test your worker from the command-line like so:
heroku run worker
To schedule a job, go into Heroku Scheduler and add the job in a similar fashion, but without the heroku run segment (else you'll get bash: heroku: command not found errors), just:
worker
Or, alternatively, directly:
php worker/myscript.php
Checking on the job
You can see the job in the app's logs. e.g.:
2017-09-01T14:19:37.397210+00:00 heroku[scheduler.9540]: Starting process with command `php worker/myscript.php`
Notes
The worker name in the Procfile could be set to something else. e.g.: myworker, mysuperduperscript, etc.
I included a web section, but it's optional if all you want is a worker / background service and don't need to serve files on the web.
Alternative: if, for whatever reason, you'd rather perform a GET/POST request on a URL, you can use the Temporize Scheduler add-on.
Related
I've been trying to connect my local files to my app using `heroku local web`, but it throws this error:
3:24:15 AM web.1 | 'vendor' is not recognized as an internal or external command,
3:24:15 AM web.1 | operable program or batch file.
[DONE] Killing all processes with signal SIGINT
3:24:15 AM web.1 Exited with exit code null
I'm sure my Procfile is there in the directory and here is the command line web: vendor/bin/heroku-php-apache2.What I'm doing wrong? What is vendor and why it's not recognizing it?
Additional info:
OS: Windows 10
buildpack: PHP
Based on the error message, it looks like you're running this in cmd.exe. Commands there often use forward slashes for options (e.g. foo /a /b) instead of dashes (e.g. foo -a -b).
I believe the slashes in your command are being interpreted as options, making vendor the command that would run.
A common pattern for using a different command local development on Windows is to create a file called Procfile.windows containing a Windows-specific command, e.g. one that uses backslashes instead of forward slashes, and then run locally as heroku local -f Procfile.windows.
But that heroku-php-apache2 binary is unlikely to run on Windows, so that will be insufficient. The getting started with PHP page is notably missing the "run the app locally" step that, for example, the Python page has.
One good option is to use Windows Subsystem for Linux to run a Linux distribution in Windows and develop there. Another might be to use something like Docker or Vagrant to run a development environment in a virtual machine.
Or, if you have PHP installed on Windows already, try using something like php -S instead of Apache:
web: php -S localhost:8000 -t main_folder/
Make sure to keep your existing Procfile as you'll want to use that on Heroku. php -S should only be used for local development.
You might also simply have better luck using PowerShell instead of cmd.exe. It is generally much better-behaved.
I'm in a multi developer program. The other developer installed PHPUnit via composer and successfully is running tests. I took the composer files, ran composer update, but when I try to run the tests, I am receiving this error:
C:\Repos\Project\TDD>php vendor/bin/phpunit
Output:
dir=$(cd "${0%[/\\]*}" > /dev/null; cd "../phpunit/phpunit" && pwd)
if [ -d /proc/cygdrive ]; then
case $(which php) in
$(readlink -n /proc/cygdrive)/*)
# We are in Cygwin using Windows php, so the path must be translated
dir=$(cygpath -m "$dir");
;;
esac
fi
"${dir}/phpunit" "$#"
This is the content of the phpunit shell script. The shebang first line #!/usr/bin/env sh is not being output, but this is the rest of the file. The problem appears to be that the PHP CLI is not executing the script, just reading it. I can't figure out how to fix that.
I am on a windows environment, and I am not running apache locally.
Things I have tried:
I have tried using full paths (eg, C:/php/php.exe) for both the php and the shell script, and that didn't matter.
I have tried reversing the slashes vendor\bin\phpunit
I can run php -v successfully, but php -f vendor/bin/phpunit still just outputs the file contents.
I have confirmed the PATH for php is accurate and restarted.
All expected vendor files do appear to be present.
Composer update is not throwing errors of any kind.
I've changed my terminal / CLI processor to use powershell instead of the default cmd.exe (same result as above)
I've confirmed encoding of the phpunit file is UTF-8 without BOM
I've tried making the php command execute the phpunit script in powershell and git bash directly with no luck --- it outputs the shell file. It seems to be that php is just not executing it, which makes me think there is a problem with my php.ini or something.
I CAN run the phpunit shell directly, such as phpunit --version, but I can't get it to run my tests.
I set the composer platform to match my cli php -v
"config": {
"platform": {
"php": "7.4.20"
}
}
Edit: Interestingly, I uploaded it all to my LAMP webserver and ran the same script there, and it is not executing there either. It's outputting the files...
There is a lot of stuff you're fiddling with while trouble-shooting your issue, so there can be only giving extended comments on it. Take it with a grain of salt and pick the pieces that make sense to you, it looks to me you're clever and should be close to the point where you connect the dots more soon than later (don't give up):
C:\Repos\Project\TDD>php vendor/bin/phpunit
This on your windows shell prompt command the php binary to execute the (php) script vendor/bin/phpunit.
And PHP does exactly this (everything else would be a surprise, right?), it executes that script.
The output you see confirms it. As php is the PHP CLI SAPI (PHP Command Line Binary), the first line starting with # is not output (you can find this behaviour described in the PHP documentation as well: https://www.php.net/manual/en/features.commandline.usage.php and on antoher place that I can't find right now that exactly describes this difference to the common mode https://www.php.net/manual/en/language.basic-syntax.phpmode.php).
You then correctly analyze:
This is the content of the phpunit shell script.
and make the note on the shebang line:
#!/usr/bin/env sh
So this looks to me that this shell script vendor/bin/phpunit is not to be executed with the given commandline:
php vendor/bin/phpunit
but instead just by:
C:\Repos\Project\TDD>vendor/bin/phpunit
Which won't (or might not) work on your windows system.
Some more background information (this applies to phpunit bin-stubs as well as other when installed as composer(1) dependencies):
composer manages these scripts (for you)
composer handles them for POSIX compatible systems as well as for others (compare the /usr/bin/env sh which is stupid, it's /bin/sh, always, may need a report on the composer project) incl. windows or windows with cygwin or WSL running on Windows, Vagrant box setups etc. pp. (yes they really care since years).
composer handles this at the time of install/update.
for windows (which I can't compare are not using it but from what I remember) composer is adding .bat or .cmd files next to the commands (as that is how Windows handles executables).
So mabye using:
C:\Repos\Project\TDD>composer exec phpunit
already solves your invocation problem.
Or
C:\Repos\Project\TDD>vendor\bin\phpunit.bat
Or
C:\Repos\Project\TDD>vendor\bin\phpunit.cmd
Or
C:\Repos\Project\TDD>vendor\bin\phpunit
does. Point in case is this: https://getcomposer.org/doc/articles/vendor-binaries.md
All in all this looks to me you got instructions from one developer working on a unixoide sytem (Mac, Linux) and you're running on Windows. This should not pose a problem on that level, however the onboarding in your team might be low or it's just the knowledge management (unfortunately after a decade or more of Stackoverflow this got worse) and you've been left alone with the trouble shooting.
It's not a programming problem, but merely getting the tooling to run.
Perhaps there is some regime about composer and running it which prevents you from looking there first. But this is hard to say on Stackoverflow.
I'd start fresh with the project, remove it from disk and install it anew. This must work, always. To not sink the current project you can do this a-new in a second directory (the project might support composer create-project to give it a quick start - that is cloning new and doing the composer install).
Similar it is that you could do a composer update in the existing project (which is intended to modify it and depending on how well the project you work with is integrated with composer and your development platform will enable or break things).
At the end of the day the common workflow is:
> rmdir vendor
(remove the vendor directory, that is the blank slate)
> composer install
(install the vendor directory, that is all PHP dependencies of the project)
> composer exec phpunit
(execute the phpunit test-runner)
Edit: Interestingly, I uploaded it all to my LAMP webserver and ran the same script there, and it is not executing there either. It's outputting the files...
Never install phpunit on a webserver system. Run it in development or CI, but not on the webserver. Period. (this has security implications, and it won't help you to execute it there, you need to run it where you develop when you're doing TDD - keep this focus for troubleshooting)
The true path to the PHP script that is represented by vendor/bin/phpunit is:
vendor/sebastianbergmann/phpunit/phpunit
(you can find it in the composer.json of phpunit https://github.com/sebastianbergmann/phpunit/blob/master/composer.json#L66)
Given your original command-line and from the various other information you give, this should work:
php vendor/sebastianbergmann/phpunit/phpunit
I'm using a Node package called exec-php to execute PHP functions within Node.js app.
I would like to push that app to Heroku, but I'm wondering how to make that, and how that would be in the PHP bin locally.
I'm using /Applications/MAMP/bin/php/php7.0.0/bin/php. What would be the path to PHP bin in Heroku?
I tested vendor/bin/heroku-php-apache2 but it doesn't work, so what would be the path to PHP binary in Heroku?
You'll need to inform the build API that you'd like to use multiple buildpacks. Try:
$ heroku buildpacks:clear
$ heroku buildpacks:add heroku/php
$ heroku buildpacks:add heroku/nodejs
Then you can inspect the compiled slug via heroku run bash to verify that the bins are where you expect them to be.
The bin directory in heroku is : .heroku/php/bin/php
I have a jenkins build job of my symfony2 project that uses grunt to start the php built in webserver so that casperjs can run functional tests against it.
To start my webserver I'm using the following command:
php app/console server:start --router=" + __dirname + "/app/config/router_test.php --env=test 0.0.0.0:9001"
However the build fails with the following message:
A process is already listening on http://0.0.0.0:9001.
Thus I have SSHed to the jenkins box and run:
netstat -tln | grep 9001
Only to get no results?!
I have restarted the server and killed all php processes, disabled iptables however none of this seems to work.
This build used to work and in the last change, all that was added were more functional tests.
Has anyone got any ideas why this could be happening?
As commented, the fix that worked for me was to change the workspace directory. Seems to have been a permissions issue with the workspace folder that jenkins created yet a chmod 777 didn't resolve it hence the new workspace folder.
I am able to make selenium scripts in the selenium IDE and also able to export it in PHPUnit. I also installed PHPUnit and the selenium-rc server (Which ran perfectly). Then I ran those scripts using the command: 'PHPUnit Testname.php' for which I got the output, But how can I Run Multiple Scripts at a time using the command..
You may specify directory or directories to run tests.
Or you can define directories in configuration file and run php unit like this:
phpunit --configuration path/to/config.xml
without any parameter it will run all tests.