It is possible to avoid this by deploying without composer.lock, but this is not recommended.On a matching major/minor version of PHP and composer, close to what is intended to be deployed on App Service - rerun composer install.Delete composer.lock from the project repository.Part of this can be due to the composer.lock file and when it was generated - for example, being generated on a different version of PHP or composer.
This will widely vary, especially with an exit status of 1. The body (reason) will typically point to a package under /vendor, syntax in relation to a certain PHP or composer version used, deprecated features, etc. This is apart of the scripts property in composer.json. The actual reason will also vary, but the body of the problem will be output after the php artisan package:discover script is ran.
#Git clone authentication failed code#
NOTE: The error code may vary, but it should generally be aligned with Linux standard error codes Script php artisan package : discover - ansi handling the post - autoload - dump event returned with error code php artisan package:discover –ansi handling the post-autoload-dump event returned with error code php extension in root of repository or in any sub-directories.Įnsure that either composer.json and/or a. composer.json file exists in the root of the repository.This means that Oryx couldn’t determine a PHP project from the file contents deployed from the logic here. This will manifest as Error: Couldn't detect a version for the platform 'php' in the repo. Using Oryx Builder Issues detecting the platform You can determine the builder through the same methods listed above. BasicBuilder: If BasicBuilder is seen, Oryx is not being used - the application will not be automatically built against a PHP toolset.You can determine the builder from /home/LogFiles/kudu/trace/yyyy-mm-ddThh-mm-ss_00aabb_000_Background_POST_api-zipdeploy_pending.xml - or other deployment logging, such as through the Logging tab in the Deployment Center. OryxBuilder: If OryxBuilder is seen, then Oryx is being used.When using Local Git, Bitbucket or External Git, Oryx is enabled by default. If you prefer to enable App Service Build Service (Oryx) then you need to add a new App Setting SCM_DO_BUILD_DURING_DEPLOYMENT= true and redeploy. NOTE When using GitHub Actions, Azure Pipelines or ZipDeploy, Oryx is not enabled by default since you are using a Remote/External builder. GitHub Actions or App Service Build Service (Oryx) or Azure PipelinesĪzure Pipelines or App Service Build Service (Oryx)Īpp Service Build Service (Oryx) or Azure PipelinesĪpp Service Build Service (Oryx) or Building Assets locally (Basic builder) During troubleshooting, it is important to understand this distiction.īefore starting you need to identify where is your source code and which is the build provider: Where is my source code?
Sometimes, after a depoyment an application may go down - this is a “post deployment” issue, and, in some cases - one may think this is a “failed deployment”, when in reality it is not - the deployment has succeeded. It is very important to identify if an issue is happening in the deployment process or post deployment (in startup of the application). This post will cover common scenarios you may encounter when deploying a PHP application on App Service Linux while Oryx is the builder.
Oryx build was aborted after 60 seconds.Uncaught Error: Failed opening required ‘/home/site/.Error: Platform ‘php-composer’ version is unsupported.php artisan package:discover –ansi handling the post-autoload-dump event returned with error code.PHP Deployments: Troubleshooting PHP deployments on App Service Linux with Oryx
0 kommentar(er)
