Flynn: Zederstapel kann nicht aufgebaut werden

Erstellt am 2. Dez. 2017  ·  4Kommentare  ·  Quelle: flynn/flynn

Alle unsere Cedar-Apps wurden in der letzten Woche oder so nicht mehr erstellt (wir haben seit einigen Tagen keinen Build mehr durchgeführt, daher bin ich mir nicht sicher, wann dies begonnen hat). Wenn ich das richtige Repo für das Buildpack gefunden habe, versucht es, eine Datei aus einem S3-Bucket herunterzuladen, wenn es diesen Fehler zurückgibt, sollte die Datei sein: https://lang-php.s3.amazonaws.com/dist-cedar- 14-stable/php-min-7.0.26.tar.gz

Diese Datei existiert, also bin ich mir nicht sicher, was hier schief läuft ...

λ  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'

Unsere composer.json und Procfile sind sehr einfach:

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"
    ]
  }
}

Profil

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

Hilfreichster Kommentar

@airways versuchen Sie es mit einem neueren PHP-Buildpack (z. B. v127 ) mit:

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

Alle 4 Kommentare

@airways versuchen Sie es mit einem neueren PHP-Buildpack (z. B. v127 ) mit:

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

@lmars Das scheint funktioniert zu haben. Ich bin verwirrt, warum dies erforderlich wäre, sollte die Version nicht automatisch aktualisiert werden? Ich hatte das Buildpack zuvor überhaupt nicht angegeben - es wurde nur automatisch erkannt.

Bei der Verwendung von Heroku musste ich Buildpacks nicht manuell aktualisieren, idealerweise würde ich erwarten, dass sich Flynn genauso verhält. Scheint, als könnte dies als Verbesserungsanforderung (wenn Flynn derzeit nicht dafür ausgelegt ist) oder als Fehler (wenn es dies bereits tun sollte) betrachtet werden.

Ich bin verwirrt, warum dies erforderlich wäre, sollte die Version nicht automatisch aktualisiert werden

Jede Version von Flynn verwendet spezifische Buildpack-Commits (z. B. das aktuelle PHP-Commit ist hier ). Diese durchlaufen das Flynn CI-System, um ihre Kompatibilität zu überprüfen, aber sie können wie oben beschrieben manuell aktualisiert werden.

Bei der Verwendung von Heroku musste ich Buildpacks nicht manuell aktualisieren, idealerweise würde ich erwarten, dass sich Flynn genauso verhält

Es liegt letztendlich in der Verantwortung des Managers eines Clusters, ein Upgrade durchzuführen (Heroku aktualisiert also seine Cluster, weil Sie dafür bezahlen). Wir sind bestrebt, die Tools bereitzustellen, um das Upgrade reibungslos zu gestalten, möchten aber lieber nicht für „automatische Upgrades“ verantwortlich sein, die dann Cluster zerstören könnten, von denen wir nichts wissen.

Das macht Sinn, danke für die Info. Ich mache weiter und schließe das.

War diese Seite hilfreich?
0 / 5 - 0 Bewertungen