Today I got a new error when trying to deploy my application to Google App Engine via the command line:
Updating module [default]...-ERROR: (gcloud.preview.app.deploy) Server responded with code [400]:
Bad Request Unexpected HTTP status 400.
Your app may not have more than 120 versions.
Please delete one of the existing versions before trying to create a new version.
I am deploying to the top level using --promote, not creating other versions. How do I fix this error?
There is also a way to do this via command line if that interests you.
gcloud preview app versions list
gcloud preview app modules delete <module_name> --version=<version_number>
UPDATE 2017
(see also CLI 400 error deploying to Google App Engine
)
List all versions:
gcloud app versions list
Delete versions v1 and v2:
gcloud app versions delete v1 v2
https://cloud.google.com/sdk/gcloud/reference/app/versions/
So I found a way to do it through the web GUI (https://console.developers.google.com). If you go to the "App Engine" tab there is a "Versions" option. Click that and it will take you to a listing of versions. Apparently one is created each time you deploy with --promote in addition to one for each version you deploy. These can be selected and then there is a trash can to click on them to delete them.
While this is not the CLI solution I would have liked, it works.
The previous answer for the command line is deprecated now. The alternative is the following:
To list all versions:
gcloud app versions list
To delete a version:
gcloud app versions delete v1 v2
More info on: https://cloud.google.com/sdk/gcloud/reference/app/versions/delete
Hope it helps!
If someone is looking for cloudbuild.yaml changes for this then here is the sample YAML config file
steps:
- name: 'gcr.io/cloud-builders/docker'
args: [ 'build', '-t', '<dockerRepository>', '.' ]
- name: "gcr.io/cloud-builders/gcloud"
args: ["app", "deploy"]
- name: "gcr.io/cloud-builders/gcloud"
entrypoint: 'bash'
args:
- '-eEuo'
- 'pipefail'
- '-c'
- |-
gcloud app versions list --format="value(version.id)" --sort-by="~version.createTime" | tail -n +6 | xargs -r gcloud app versions delete --quiet
To remove the last version only for a specific service. Keep in mind you could have several services in the same GCP.
Fist get the service name
gcloud services list --available
and then, remove it
gcloud app versions list --format="value(version.id)" --sort-by="~version.createTime" --service=SERVICE_NAME | tail -n -1 | xargs gcloud app versions delete --quiet
Related
I cannot get a Release pipeline in Azure DevOps to successfully deploy build files from a React app to an Azure App Service.
This is the YAML file for the app:
trigger:
- main
variables:
buildConfiguration: 'Release'
stages:
- stage: Build
displayName: 'Build my web application'
jobs:
- job: 'Build'
displayName: 'Build job'
pool:
vmImage: ubuntu-latest
demands:
- npm
steps:
- task: NodeTool#0
inputs:
versionSpec: '16.x'
displayName: 'Install Node.js'
- script: |
npm install
npm run build
displayName: 'npm install and build'
- task: PublishBuildArtifacts#1
inputs:
PathtoPublish: 'build'
ArtifactName: 'drop'
publishLocation: 'Container'
displayName: 'Build artifact'
As you'd expect, this puts the resultant build files in 'drop'. I can confirm this by inspecting the contents of 'drop' as it is a Published Artifact I can click on in the Summary tab for the Build process.
It's the Release that fails. This is the log for the release:
2022-03-28T11:29:39.9940600Z ##[section]Starting: Azure Web App Deploy: my-app-serv
2022-03-28T11:29:39.9952321Z ==============================================================================
2022-03-28T11:29:39.9952723Z Task : Azure Web App
2022-03-28T11:29:39.9953008Z Description : Deploy an Azure Web App for Linux or Windows
2022-03-28T11:29:39.9953295Z Version : 1.200.0
2022-03-28T11:29:39.9953540Z Author : Microsoft Corporation
2022-03-28T11:29:39.9953833Z Help : https://aka.ms/azurewebapptroubleshooting
2022-03-28T11:29:39.9954210Z ==============================================================================
2022-03-28T11:29:40.3697650Z Got service connection details for Azure App Service:'my-app-serv'
2022-03-28T11:29:42.3999385Z Package deployment using ZIP Deploy initiated.
2022-03-28T11:30:18.0663125Z Updating submodules.
2022-03-28T11:30:18.0670674Z Preparing deployment for commit id 'dc023bbe-d'.
2022-03-28T11:30:18.0672154Z Repository path is /tmp/zipdeploy/extracted
2022-03-28T11:30:18.0673178Z Running oryx build...
2022-03-28T11:30:19.1423345Z Command: oryx build /tmp/zipdeploy/extracted -o /home/site/wwwroot --platform nodejs --platform-version 16 -i /tmp/8da10ae4b1f9200 -p compress_node_modules=tar-gz --log-file /tmp/build-debug.log
2022-03-28T11:30:19.1431972Z Operation performed by Microsoft Oryx, https://github.com/Microsoft/Oryx
2022-03-28T11:30:19.1453191Z You can report issues at https://github.com/Microsoft/Oryx/issues
2022-03-28T11:30:19.1453685Z
2022-03-28T11:30:19.1454256Z Oryx Version: 0.2.20211207.1, Commit: 46633df49cc8fbe9718772a3c894df221273b2af, ReleaseTagName: 20211207.1
2022-03-28T11:30:19.1457307Z
2022-03-28T11:30:19.1463475Z Build Operation ID: |DTbD+7CrQyM=.49dfa157_
2022-03-28T11:30:19.1465355Z Repository Commit : dc023bbe-d46e-46f2-9d49-6e8157706c19
2022-03-28T11:30:19.1465695Z
2022-03-28T11:30:19.1466122Z Detecting platforms...
2022-03-28T11:30:19.1466558Z Could not detect any platform in the source directory.
2022-03-28T11:30:19.1467416Z Error: Couldn't detect a version for the platform 'nodejs' in the repo.
2022-03-28T11:30:19.1469069Z Error: Couldn't detect a version for the platform 'nodejs' in the repo.\n/opt/Kudu/Scripts/starter.sh oryx build /tmp/zipdeploy/extracted -o /home/site/wwwroot --platform nodejs --platform-version 16 -i /tmp/8da10ae4b1f9200 -p compress_node_modules=tar-gz --log-file /tmp/build-debug.log
2022-03-28T11:30:19.1469950Z Deployment Failed.
2022-03-28T11:30:19.1510175Z ##[error]Failed to deploy web package to App Service.
2022-03-28T11:30:19.1525344Z ##[error]To debug further please check Kudu stack trace URL : https://$my-app-serv:***#my-app-serv.scm.azurewebsites.net/api/vfs/LogFiles/kudu/trace
2022-03-28T11:30:19.1527823Z ##[error]Error: Package deployment using ZIP Deploy failed. Refer logs for more details.
2022-03-28T11:30:30.1233247Z Successfully added release annotation to the Application Insight : my-app-serv
2022-03-28T11:30:32.2997996Z Successfully updated deployment History at (CUT)
2022-03-28T11:30:34.0322983Z App Service Application URL: http://my-app-serv.azurewebsites.net
2022-03-28T11:30:34.0390276Z ##[section]Finishing: Azure Web App Deploy: my-app-serv
The Release uses Azure Web App Deploy. App Type is 'Web App on Linux'. 'Package or Folder' is the 'drop' folder. Runtime stack is '16 LTS (NODE|16-lts)' (but it also doesn't work if that's empty).
The drop folder does not contain zipped output. I don't understand why the Release operation is referred to as a Zip Deploy. Am I missing something to avoid the error 'Error: Couldn't detect a version for the platform 'nodejs' in the repo.'?
I'm just expecting the contents in the 'drop' folder to be successfully copied to App Service, and the web app run so I can test it (and in the long time, setup automated tests).
I've tried a number of different things with the Build, including zipping the build artifacts, with no luck. I don't think the build is the problem though, as the files in the 'drop' folder are the files I want copied.
So I think it's the Release that's the problem. But that looks so simple.
I start with an Agent and add an Azure Web App deployment task. It seems to successfully pickup the drop folder, as I've tried other values that show an obvious error when that is wrong. The target App Service is Linux, so the Web App Deploy App type is set to 'Web App on Linux'.
I've seen a few different approaches in stackoverflow, but no answers to this approach. Maybe I'm going about this the wrong way, but on the surface it looks right, as if I get this right, I can easily manage manual deployments, authorisations, etc. as supported by Releases.
Thanks in advance
One of the possible workarounds that you can try is to make the SCM_DO_BUILD_DURING_DEPLOYMENT= FALSE.
After making this as false, you should be able to deploy the app.
Also please refer these links with similar issue for more information.
Reference 1 ,
Reference 2
Greetings stackoverflow community! First time asker, long time user.
I am testing out my cloudbuild.yaml file locally using Cloud Build Local component and Secret Manager and it is failing on "availableSecrets".
Error message: Error loading config file: unknown field "availableSecrets" in cloudbuild.Build
OS Platform: Windows 10/WSL2/Ubuntu 18.04
cloud-build-local: v0.5.2
Docker engine: v20.10.2
Nodejs version: v14.15.3
NPM version: 6.14.9
gcloud version: 326.0.0
Installed components: [BigQuery Command Line Tool, Cloud Datastore Emulator, Cloud SDK Core Libraries, Cloud Storage Command Line Tool, Google Cloud Build Local Builder, gcloud Beta Commands]
Documentation on Cloud Build build file: https://cloud.google.com/cloud-build/docs/build-config
Documentation to configure secrets with cloud build: https://cloud.google.com/cloud-build/docs/securing-builds/use-secrets
Documentation for cloud build local: https://cloud.google.com/cloud-build/docs/build-debug-locally
Steps performed:
Added secrets to Secret Manager
Enabled API between Cloud Build and Secrets Manager
Added cloudbuild service account as member of each secret password.
Added IAM permission Secret Manager Secrets Accessor to cloudbuild user. I don't know where I got this info from but it is residual at this point from other attempts to use Secret Manager with cloudbuild. I am not sure of the difference between applying access here vs applying to the Secret Manager secret.
Command: cloud-build-local --config=cloudbuild.staging.yaml --dryrun=false .
cloudbuild.staging.yaml:
- name: gcr.io/cloud-builders/npm
entrypoint: 'npm'
args: [ 'install' ]
- name: 'gcr.io/cloud-builders/gcloud'
args: ["app", "deploy"]
env:
- 'DAO_FACTORY=datastore'
- 'POLL_INTERVAL=15'
- 'PROMPT=staging>'
- 'ENVIRONMENT=staging'
- 'NAMESPACE=staging'
- 'RESET_DATASTORE=false'
secretEnv: ['ADMIN_USER', 'SUPER_ADMINS', 'BOT_TOKEN']
availableSecrets:
secretManager:
- versionName: projects/{project token}/secrets/SYSTEM_USER/versions/1
env: 'ADMIN_USER'
- versionName: projects/{project token}/secrets/SUPER_ADMINS/versions/1
env: 'SUPER_ADMINS'
- versionName: projects/{project token}/secrets/BOT_TOKEN/versions/2
env: 'BOT_TOKEN'```
Tag: cloud-build-local. I guess without reputation a meaningful tag cannot be created. Maybe an esteemed community member will create this as this may be specific to cloud-build-local only.
Support for Google Secret Manager in Google Cloud Build descriptor file is apparently very new and does not appear to be supported by cloud-build-local component at this time; please see comment from Guillaume about feature being a week old. When cloud build descriptor is ran in Cloud Build, it works fine.
I fixed a similar issue by upgrading the gcloud tool.
I'm trying the following tutorial.
Automatic serverless deployments with Cloud Source Repositories and Container Builder
But I got the error below.
$ gcloud container builds submit --config deploy.yaml .
BUILD
Already have image (with digest): gcr.io/cloud-builders/gcloud
ERROR: (gcloud.beta.functions.deploy) Error creating a ZIP archive with the source code for directory .: ZIP does not support timestamps before 1980
ERROR
ERROR: build step 0 "gcr.io/cloud-builders/gcloud" failed: exit status 1
I'm now trying to solve it. Do you have any idea? My gcloud is the latest version.
$ gcloud -v
Google Cloud SDK 193.0.0
app-engine-go
app-engine-python 1.9.67
beta 2017.09.15
bq 2.0.30
core 2018.03.09
gsutil 4.28
Sample google cloud function code on the tutorial.
#index.js
exports.f = function(req, res) {
res.send("hello, gcf!");
};
#deploy.yaml
steps:
- name: gcr.io/cloud-builders/gcloud
args:
- beta
- functions
- deploy
- --trigger-http
- --source=.
- --entry-point=f
- hello-gcf # Function name
#deploying without Cloud Container Builder is fine.
gcloud beta functions deploy --trigger-http --source=. --entry-point=f hello-gcf
Container Builder tars your source folder. Maybe something in your . directory has corrupted dates? That's why moving it to the source folder fixes it.
While I don't know the reason, I found a workaround.
(1) make src directory and move index.js into it.
├── deploy.yaml
└── src
└── index.js
(2) deploy via Cloud Container Builder.
$ gcloud container builds submit --config deploy.yaml ./src
I ran into the same issue now. I could not solve it but at least I found out where it comes from.
When you locally submit your build there is a tar created and uploaded to a bucket. In this tar the folders are created at 01.01.1970:
16777221 8683238 drwxr-xr-x 8 user staff 0 256 "Jan 1 01:00:00 1970" "Jan 1 01:00:00 1970" "May 15 12:42:04 2019" "Jan 1 01:00:00 1970" 4096 0 0 test
This issue only occurs locally. If you have a github build trigger it works
I recently came across the same issue using Cloud Build (the successor to Container Builder).
What helped was adding a step to list all the files/folders in the Cloud Build environment (default directory is /workspace) to identify the problematic file/folder. You can do this by overriding the gcloud container's entrypoint to execute the ls command.
steps
- name: gcr.io/cloud-builders/gcloud
entrypoint: "ls"
args: ["-la", "/workspace"]
I have a Google Cloud Platform project with several GCE instances that I use daily. I decided I wanted to mess around with app engine and deployed a sample version of an application that I would now like to get rid of. While I've disabled the app is there any way to delete it without deleting the entire project? I've tried appcfg.sh delete_version appengine-dir -V 1 but I get Bad argument: You must specify a version ID via -V or --version. I've tried doing appcfg.sh delete_version appengine-dir --version=1 but get the same thing. I'm going to be really disappointed if I have to download all the data off of my instances and re-deploy the entire project just to get rid of an app engine app which will never be used again. I am aware this is technically speaking a duplicate question but all of the answers I've found are for older versions of app engine and I just get redirected to the new console which doesn't seem to have the same options.
EDIT: Turns out doing appcfg.sh -A projID -V 1 delete_version appengine-dir works and doesn't give me any of those errors but I get Cannot delete the default version of the default module. I get the feeling I just can't do this at all which I personally find really really dumb.
It is not currently possible to delete the default module of an App Engine application.
There is however an open feature request Issue 12984 for this. Feel free to star this public issue to support this request and receive updates regarding its progress.
This is what I put in my cloudbuild.yaml to delete versions older than count 5.
# Remove old GAE versions
- name: 'gcr.io/cloud-builders/gcloud'
entrypoint: 'bash'
args:
- '-c'
- |
versions=$(gcloud app versions list \
--service default \
--sort-by '~version' \
--format 'value(VERSION.ID)' | sed 1,5d)
for version in $versions; do
gcloud app versions delete "$version" \
--service default \
--quiet
done
This can now be accomplished on the command line using:
gcloud app versions delete <version-name>
This started after I ran the latest gcloud update:
gcloud components update
I used to be able to deploy my app something like this:
appcfg.py update app.yaml
Now I get:
appcfg.py: command not found
Is there a new gcloud command for deploying App Engine apps?
It appears the most recent version of gcloud dropped appcfg.py from the bin directory.
$ ls ~/google-cloud-sdk/bin/
bootstrapping bq dev_appserver.py gcloud git-credential-gcloud.sh gsutil
I found the appcfg.py script under the platform directory:
$ ls ~/google-cloud-sdk/platform/google_appengine
api_server.py dev_appserver.py LICENSE RELEASE_NOTES
appcfg.py ...
By linking it back to the bin directory, I was able to restore the command.
ln -sv ~/google-cloud-sdk/platform/google_appengine/appcfg.py ~/google-cloud-sdk/bin/
Credit to this post for helping me to figure this out.
gcloud app deploy is the preferred way when using gcloud. If you download the stand alone Google App Engine SDK, then you will have appcfg.py available.
https://cloud.google.com/sdk/gcloud/reference/app/deploy
in my case, i needed to run the following:
sudo ln -sv /usr/local/google-cloud-sdk/platform/google_appengine/appcfg.py /usr/local/google-cloud-sdk/bin/
using gcloud app deploy --project project-appengine-id
You'll need to have a billing account
As the standalone Google App Engine SDK is no longer available, if you still need access to appcfg.py (for instance, if you are trying to set up Eclipse for an App Engine Standard project that uses Python 2 according to these instructions), I have found that one way to get it is to just install an older version of the Cloud SDK.
Specifically, appcfg.py was apparently removed in Cloud SDK version 344.0.0 when the Python SDK was updated to version 1.9.93, so you can run:
gcloud components install app-engine-python
gcloud components update --version 343.0.0
and this will give you the most recent version of the app-engine-python component that still had that file.