Cedar stack fails to build

[airways]

All of our Cedar apps have stopped building within the last week or so (we haven't done a build for a few days, so I'm unsure when this started happening). If I have found the right repo for the buildpack it is trying to download a file from an S3 bucket when it returns this error, the file should be: https://lang-php.s3.amazonaws.com/dist-cedar-14-stable/php-min-7.0.26.tar.gz

This file does exist so I'm not sure what's going wrong here...

λ  git push flynn-dev master                                                        
Counting objects: 1, done.                                                          
Writing objects: 100% (1/1), 185 bytes | 0 bytes/s, done.                           
Total 1 (delta 0), reused 0 (delta 0)                                               
remote: -----> Building example...                                                 
remote: -----> PHP app detected                                                     
remote: -----> Bootstrapping...                                                     
remote:                                                                             
remote:        !     ERROR: Failed to download minimal PHP for bootstrapping.       
remote:        Please try again, or contact support if this problem persists.       
remote:                                                                             
remote: ERROR: Build failed: exec: job exited with status 1                         
To https://git.example.example.com/example.git
 ! [remote rejected] master -> master (pre-receive hook declined)                   
error: failed to push some refs to 'https://git.example.example.com/example.git'

Our composer.json and Procfile are very simple:

composer.json

{
  "require": {
     "php": "^5.6.0",
     "ext-mbstring": "*",
     "ext-gd": "*",
     "ext-mcrypt": "*",
     "ext-redis": "*"
  },
  "scripts": {
    "compile": [
      "rm -rf craft/storage/",
      "mkdir -p craft/storage/runtime/compiled_templates",
      "mkdir -p craft/storage/backups",
      "mkdir -p craft/storage/runtime/assets",
      "mkdir -p craft/storage/runtime/cache",
      "mkdir -p craft/storage/logs",
      "mkdir -p craft/storage/sessions",
      "chmod -R 0777 craft/storage",
      "ls -al craft/storage",
      "ls -al craft/storage/runtime",
      "ls -al craft/storage/runtime/compiled_templates",
      "cp public/dist.htaccess public/.htaccess"
    ]
  }
}

Procfile

web: vendor/bin/heroku-php-apache2 public/

[lmars]

@airways try using a more recent PHP buildpack (e.g. v127) with:

$ flynn env set BUILDPACK_URL=https://github.com/heroku/heroku-buildpack-php.git#v127

[airways]

@lmars That seems to have worked. I'm puzzled why this would be needed, shouldn't the version be automatically upgraded? I hadn't previously specified the buildpack at all -- it was just auto detected.

When using Heroku I've not needed to upgrade buildpacks manually, ideally I would expect Flynn to behave the same way. Seems like this could be considered an enhancement request (if Flynn is not currently designed to do it) or a bug (if it should already be doing it).

[lmars]

I'm puzzled why this would be needed, shouldn't the version be automatically upgraded

Each release of Flynn uses specific buildpack commits (e.g. the current PHP one is here). These go through the Flynn CI system to check they are compatible, but they can be manually upgraded as outlined above.

When using Heroku I've not needed to upgrade buildpacks manually, ideally I would expect Flynn to behave the same way

It is ultimately the responsibility of the manager of a cluster to upgrade (so Heroku upgrade their clusters because you pay them to). We aim to provide the tools to make upgrading a smooth process, but would rather not be responsible for "auto-upgrades" which could then break clusters we know nothing about.

[airways]

That makes sense, thanks for the information. I'll go ahead and close this.