I have a Python 3 project which I am hosting on Google AppEngine Standard. Until a couple of days ago I was able to deploy normally (right since I did the initial setup in July 2019) until a couple of days ago. Now I get the following response:
starting build "abc"
FETCHSOURCE
BUILD
Starting Step #0 - "fetcher"
Step #0 - "fetcher": Already have image (with digest): gcr.io/cloud-builders/gcs-fetcher
Step #0 - "fetcher": Fetching manifest gs://staging.my-project.appspot.com/ae/xxx/manifest.json.
Step #0 - "fetcher": Processing 312 files.
Step #0 - "fetcher": Failed to fetch gs://staging.my-project.appspot.com/xxx, will no longer retry: fetching "gs://staging.my-project.appspot.com/xxx" with timeout 1h0m0s to temp file "/workspace/.download/staging.my-project.appspot.com-xxx": source-context.json SHA mismatch, got "xxx", want "yyy"
Step #0 - "fetcher": Failed to download at least one file. Cannot continue.
Finished Step #0 - "fetcher"
ERROR
ERROR: build step 0 "gcr.io/cloud-builders/gcs-fetcher" failed: step exited with non-zero status: 1
Any idea why this would be happening and how to fix it?
P.S. I use the following command for deployment:
gcloud --project my-project app deploy app.yaml
After conversation with Google engineers (https://issuetracker.google.com/issues/154588981?pli=1) the following worked:
Remove the source-context.json file
Delete the bucket where the deployment files are, e.g. gs://staging.my-project.appspot.com
Deploy again
If you need the source-context.json file, you can follow these steps: https://www.google.com/url?q=https://cloud.google.com/debugger/docs/source-context&sa=D&usg=AFQjCNHMB7Dm_jISwG2AnpokQ7XN5GmLAw
This is what I did and it worked for me:
1.
Go to the link that in the error description:
2.
You'll see there some lines for staging fail, copy the name of the file in the first line:
3.
Go to the Google storage here and enter to a bucket with name that starts with "staging.***"
And inside that bucket I search for the string I copy in step 2:
4.
Deleted that file, and retry that steps for every line you'll see in the error details link (in my example there are 4 rows).
5.
Deploy again!
I had a similar problem after I changed a local file during a gcloud app deploy with a long upload (2200 files, because of a wrong .gcloudignore).
I fixed it by deleting the changed file in the cloud storage browser, and deploying again with gcloud app deploy.
For anyone using a NextJS project the solution may be to delete the .next folder and rebuild your project. It seems the some of the cache files from next can become out of sync.
From the root of your project:
rm -rf .next && next build
then redeploy as usual
Related
I am deploying a trivial App Engine Standard Environment app. (Literally the shortest possible, a Python 3 "hello world".) I am using Macbook with zshell.
If I redirect standard error to file, I get an error (below) every time.
gcloud app deploy -q 2>>err.log
If I omit the redirection, it succeeds every time.
There is no difference between using > or >>. Redirecting with a pipe, e.g. to grep, does not cause the problem.
So this is a "solution" (by sending output through a passthrough grep) that does what I need and does not trigger the problem, but this is very roundabout.
gcloud app deploy -q 2>&1 >/dev/null |egrep "." >> err.txt
Note that I use -q, so waiting for my Y for approval is not the issue.
The error is this. (Identifiers were anonymized.)
..................failed.
ERROR: (gcloud.app.deploy) Error Response: [9] Cloud build BUILD_ID status: FAILURE
Build error details: Failed to download at least one file. Cannot continue.
Full build logs: https://console.cloud.google.com/cloud-build/builds/BUILD_ID?project=PROJECT_ID
Looking at the logs, I see this.
starting build "BUILD_ID"
FETCHSOURCE
BUILD
Starting Step #0 - "fetcher"
Step #0 - "fetcher": Already have image (with digest): gcr.io/cloud-builders/gcs-fetcher
Step #0 - "fetcher": Fetching manifest gs://staging.joshua-playground.appspot.com/ae/BUILD_ID/manifest.json.
Step #0 - "fetcher": Processing 728 files.
Step #0 - "fetcher": Failed to fetch gs://staging.my-project.appspot.com/BUILD_ID, will no longer retry: fetching "gs://staging.my-project.appspot.com/BUILD_ID" with timeout 1h0m0s to temp file "/workspace/.download/staging.joshua-playground.appspot.com-BUILD_ID": err SHA mismatch, got "SHA_VALUE", want "SHA_VALUE"
Step #0 - "fetcher": Failed to download at least one file. Cannot continue.
Finished Step #0 - "fetcher"
ERROR
ERROR: build step 0 "gcr.io/cloud-builders/gcs-fetcher" failed: step exited with non-zero status: 1
Google has confirmed this issue. Please track it here.
I want to deploy an update to our app but we have an issue with gcloud command which failed to "Conflicting SHA1 sum for file". Here is the output:
➜ gcloud app deploy xxx-xxx-xxxx.yaml --project xxx-xxx-xxxx --quiet
Services to deploy:
descriptor: [/home/vzool/Workspace/xxx-xxxx-xxxxxxxxxxx/xxx-xxx-xxxx.yaml]
source: [/home/vzool/Workspace/xxx-xxxx-xxxxxxxxxxx]
target project: [xxx-xxx-xxxx]
target service: [default]
target version: [20180917t110153]
target url: [https://xxx-xxx-xxxx.appspot.com]
Beginning deployment of service [default]...
╔════════════════════════════════════════════════════════════╗
╠═ Uploading 1 file to Google Cloud Storage ═╣
╚════════════════════════════════════════════════════════════╝
File upload done.
Updating service [default]...failed.
ERROR: (gcloud.app.deploy) Error Response: [3] The following errors occurred while copying files to App Engine:
File https://storage.googleapis.com/staging.xxx-xxx-xxxx.appspot.com/c819d7599ceb31df8d4370eed1981defcb5034c6 failed with: Conflicting SHA1 sum for file. Expected "ddb6af3b_cf4bff57_613fb78d_208480fa_1717b3c4" but received "c819d759_9ceb31df_8d4370ee_d1981def_cb5034c6".
Details: [
[
{
"#type": "type.googleapis.com/google.rpc.ResourceInfo",
"description": "Conflicting SHA1 sum for file. Expected \"ddb6af3b_cf4bff57_613fb78d_208480fa_1717b3c4\" but received \"c819d759_9ceb31df_8d4370ee_d1981def_cb5034c6\".",
"resourceName": "https://storage.googleapis.com/staging.xxx-xxx-xxxx.appspot.com/c819d7599ceb31df8d4370eed1981defcb5034c6",
"resourceType": "file"
}
]
]
I do delete this file c819d7599ceb31df8d4370eed1981defcb5034c6 but everytime new hash will be generated, delete entire block staging.xxx-xxx-xxxx.appspot.com and I did clear Memcache but with no luck trying all these options! :(
I don't know what to do anymore with this, any suggestions may help me out?
Thanks
I think after sometime in research the issue, the app itself has a live feature which lead to update one file while you open live page.
So, that change what gcloud uploaded.
gcloud upload then verify. And if file changed after upload and before verify gcloud will through this error on your face. Ha ha ha ^_^
OP's answer seemed to indicate that a file got touched during the gcloud deploy process.
The solution for me was to:
git checkout some random branch
git checkout the branch I was actually trying to deploy again
run gcloud app deploy . --version my_version_id --project my_project_id
I'm having an issue where an App Engine project will no longer build remotely (via gcloud app deploy)
This has started out of the blue, with no code changes at this end. Not sure if relevant, but it's a go 1.9 project deploying to the App Engine Flex environment.
I'm not sure how to test this in the same environment as the build, since the error is coming from Google's Container Registry
Here is the log from the Container Registry console
starting build "73f85b4d-7370-41bd-bbb2-bcf42fc38873"
FETCHSOURCE
Fetching storage object: gs://staging.[project].appspot.com/us.gcr.io/[project]/appengine/default.1ed3c690ead06f27aa651a30fab342611:latest#1531698266413753
Copying gs://staging.[project].appspot.com/us.gcr.io/[project]/appengine/default.1ed3c690ead49f731806f27aa630fab342611:latest#1531698266413753...
Operation completed over 1 objects/1.7 MiB.
BUILD
Starting Step #0
Step #0: Pulling image: gcr.io/gcp-runtimes/go1-builder#sha256:c62ac3fbec31ddec70601d6c5b44d07063bcff6a823bdcf5e0bbaa9d3799d1db
Step #0: sha256:c62ac3fbec31ddec70601d6c5b44d07063bcff6a823bdcf5e0bbaa9d3799d1db: Pulling from gcp-runtimes/go1-builder
Step #0: Digest: sha256:c62ac3fbec31ddec70601d6c5b44d07063bcff6a823bdcf5e0bbaa9d3799d1db
Step #0: Status: Downloaded newer image for gcr.io/gcp-runtimes/go1-builder#sha256:c62ac3fbec31ddec70601d6c5b44d07063bcff6a823bdcf5e0bbaa9d3799d1db
Step #0: exec: "gcc": executable file not found in $PATH Finished
Step #0 ERROR ERROR: build step 0 "gcr.io/gcp-runtimes/go1-builder#sha256:c62ac3fbec31ddec70601d6c5b44d07063bcff6a823bdcf5e0bbaa9d3799d1db" failed: exit status 2
It looks like you are using container gcr.io/gcp-runtimes/go1-builder as your build step. Looking at the source in GitHub, I see that there have been no updates since ~late June. I see in the Dockerfile that the base image in the FROM directive is gcr.io/google-appengine/debian9:latest, and a look at that image reveals no gcc installed. I see no step in the Dockerfile installing gcc, and looking at your build step image confirms that it isn't there:
~$ docker run --rm -t -i --entrypoint /bin/bash gcr.io/gcp-runtimes/go1-builder#sha256:c62ac3fbec31ddec70601d6c5b44d07063bcff6a823bdcf5e0bbaa9d3799d1db -- which gcc
Unable to find image 'gcr.io/gcp-runtimes/go1-builder#sha256:c62ac3fbec31ddec70601d6c5b44d07063bcff6a823bdcf5e0bbaa9d3799d1db' locally
sha256:c62ac3fbec31ddec70601d6c5b44d07063bcff6a823bdcf5e0bbaa9d3799d1db: Pulling from gcp-runtimes/go1-builder
e154cec6816f: Pull complete
<pulls elided>
Digest: sha256:c62ac3fbec31ddec70601d6c5b44d07063bcff6a823bdcf5e0bbaa9d3799d1db
Status: Downloaded newer image for gcr.io/gcp-runtimes/go1-builder#sha256:c62ac3fbec31ddec70601d6c5b44d07063bcff6a823bdcf5e0bbaa9d3799d1db
~$
Perhaps an earlier version of the base debian9 image had it installed, you could dig into history to look. But it looks like there is no recent change to the go1-builder image to remove gcc.
If you need gcc, you can always separate building your app from deploying it. Build with your own cloudbuild.yaml via gcloud container builds submit and then deploy the built container using gcloud app deploy --image-url=... With full control over the build, you can always based on the go-builder image and install additional tooling you need like gcc on top of that before using Docker to build your final app container.
I'm new on Google App Engine. And, I'm getting an issue that I can't solve.
I've a very simple app (developped in Go) like this :
main/
| model/
| | user.go
| main.go
| app.yaml
These are the imports of main.go :
import (
"github.com/julienschmidt/httprouter"
"log"
"net/http"
)
My code works well when I run it locally.
But, when I try to publish it on my Google App Engine instance, I receive this error :
$ gcloud app deploy
You are about to deploy the following services:
- <MY_APP_ENGINE_URL> (from [<MY_LOCAL_YAML_PATH>])
Deploying to URL: [<MY_APP_ENGINE_URL>]
Do you want to continue (Y/n)? Y
Beginning deployment of service [default]...
Some files were skipped. Pass `--verbosity=info` to see which ones.
You may also view the gcloud log file, found at
[<LOCAL_APP_ENGINE_LOG>].
File upload done.
Updating service [default]...failed.
ERROR: (gcloud.app.deploy) Error Response: [9] Deployment contains files that cannot be compiled: Compile failed:
2017/05/27 14:48:24 go-app-builder: build timing: 5×compile (301ms total), 0×link (0s total)
2017/05/27 14:48:24 go-app-builder: failed running compile: exit status 2
main.go:4: can't find import: "github.com/julienschmidt/httprouter"
What did I do wrong ?
EDIT :
This is the content of my app.yaml file :
runtime: go
api_version: go1
handlers:
- url: /.*
script: _go_app
App Engine environment doesn't contain your dependencies, you can add an script to do a go get ... for each one but it's too hacky and Go has a solution for that, we can save our dependencies in a vendor folder on the root of our project.
Quick solution:
# Instal godep:
go get -v -u github.com/tools/godep
cd your/project/path
godep save
Now try to deploy again, you'll see a vendor folder in your project, don't remove it and add it to your git source, that folder contains all your third party dependencies like your httprouter (it's my favorite :) )
Note You can use other tools to save your dependencies
I haven't used the gcloud tool, but back in the day when goapp was the tool you had to create github.com/julienschmidt/httprouter (with the lib's source in it, of course) directly under you'r main and then deploy.
AFAIK the App Engine's go version is currently 1.6 which means that while the vendoring is on by default, it can be switched off - perhaps thats the case and thats why #Yandry Pozo's suggestion doesn't work.
I am following the instructions on https://cloud.google.com/appengine/docs/go/googlecloudstorageclient/download to begin migrating some code from the, now deprecated, Files API to the new Cloud Storage API without success.
The steps I'm following are ...
I'm running appengine v1.9.23 which is later than the required appengine v1.8.1.
My $GOPATH is set, so I skip step #1.
I proceed to step #2:
goapp get -u golang.org/x/oauth2
goapp get -u google.golang.org/cloud/storage
I am not developing on a managed VM, so I skip step #3.
Now when I run the application, I get:
go-app-builder: Failed parsing input: parser: bad import "syscall" in goapp/src/golang.org/x/net/internal/nettest/error_posix.go
What am I doing wrong?
Steps to reproduce
Download an install the Google Appengine runtime, version 1.9.23 from https://console.cloud.google.com/storage/browser/appengine-sdks/featured/ . Follow the installation instructions documented on https://cloud.google.com/appengine/downloads?hl=en
Create an appengine project directory:
% mkdir $HOME/myapp
Create a new app.yaml file as ~/myapp/app.yaml. Read the directions on the Google website for details: https://cloud.google.com/appengine/docs/go/config/appconfig
I use a version that does not have the static resources:
application: myapp
version: alpha-001
runtime: go
api_version: go1
handlers:
- url: /.*
script: _go_app
Create a location for the Go source files.
% mkdir $HOME/myapp/go
Set your GOPATH to the location of your sources
% export GOPATH=$HOME/myapp/go
Get the Go appengine example project: https://github.com/golang/example
% goapp get github.com/golang/example/appengine-hello
This command will download the example app to the first path entry in the GOPATH
Install the Google Cloud Storage client libraries as directed in https://cloud.google.com/appengine/docs/go/googlecloudstorageclient/download . Reference the steps at the top of this question for more details. Following the directions should result in you running 2 commands:
% go get -u golang.org/x/oauth2
% go get -u google.golang.org/cloud/storage
Attempt to run your go application
% goapp serve
You will see the following compilation error (no stack trace):
2015/12/23 10:37:07 go-app-builder: Failed parsing input: parser: bad import "syscall" in go/src/golang.org/x/net/ipv6/control_unix.go
This error is caused by either of two scenarios:
1) Implicitly importing syscall by importing another package that uses it, as referenced in this related question.
2) Having your package source files in your GOPATH located in a directory at or below the same level as your project's app.yaml (eg. app.yaml in ~/go, and packages sources in ~/go/gopath/src). If a package like x/net/internal/nettest exists in your GOPATH the syscall import will be parsed by goapp at compile time and throw the compilation error.
Avoiding these two scenarios should be sufficient to prevent any bad import "syscall" errors or related compilation errors.
Reproduced the initial steps above and got a similar error, even if not explicitly mentioning syscall. However, running “goapp serve” in the appengine-hello directory results in no error at all.
Adam’s explanation at point 2 applies here correctly: one needs to place the app.yaml file at the right level in the directory structure.
sirupsen/logrus references syscall.
They have an appengine tag specified, not to include syscall so it's usable in AppEngine, something like go build -tags appengine as per issue 310.
However I haven't yet succeeded including it in an AppEngine project so that this build param could be forwarded and specified somewhere so that it goes through. I'll come back to update if I manage.