How to run a Node app (NextJS) on gcloud from github? - node.js

I have followed these steps:
I installed `Google Cloud Build app on Github, linked it to Cloud Build and configured it to use a certain repository (a private one)
I set up a trigger at Cloud Build: Push to any branch
the project has no app instances after deploying (App Engine -> Dashboard)
My cloudbuild.yarml looks like this:
steps:
- name: 'gcr.io/cloud-builders/gcloud'
args: ['app', 'deploy', '--project=project-name', '--version=$SHORT_SHA']
If I try to run the trigger manually: I get this error in Google Cloud:
unable to get credentials for cloud build robot
I have also tried to set IAM roles based on this article but using #cloudbuild.gserviceaccount.com doesn't seem to be a valid "member" (perhaps I need two projects, one for running and one for building the app?)
How do I fill the gaps / fixes the errors mentioned?

It seems the error message looking for credential that has the required permission. From the article that you are following, in the step #4, don't add manually the Service Account for Cloud Build. Check if you enable the Cloud Build API in your project, if the API is disabled try to enable. It will automatically create the Service Account for Cloud Build and look likes this:
[PROJECT_NUMBER]#cloudbuild.gserviceaccount.com
Once the service account is created, go to Cloud Build > Setting page and enable the required roles for you application.

Related

How to configure appsettings on a auto-generated preview environment

How can I change the appsettings on the preview environemnts that are generated by the Azure Static Web Apps CI/CD Github Action for each pull request?
I can go to the portal, navigate to the generated environment and change its appsettings. Doing this manually for each new pull request is error prone and will become tedious really fast.
I couldn't find any reference to this in the Build Configuration For Azure Static Webapps docs so I'm assuming it can't be configured that way.
I also couldn't find any reference to SWA environments in the CLI docs.
I looked into deployment environments but it looks like this is some other kind of deployment environment as it keeps mentioning devcenter.
In Azure Portal, While Creating Static Web App, after providing the GitHub Repo and Branch details, we will get an option to preview the Workflow file.
I can go to the portal, navigate to the generated environment and change its appsettings
Yes, In Configuration Section we have an option to add the App settings. But it is a manual work, which is not advised to follow.
Once we click on Review + create and create the Static Web App, a new folder with name .github/workflows will be created in the GitHub Repository.
It contains the same workflow file (preview file), which we saw while creating the Static WebApp in Azure Portal.
We can edit the Workflow manually.
To update the appsettings/configurations in the workflow, we can specify the steps in the existing workflow file.
We can use either Powershell/Azure CLI commands to update the Appsettings.
az staticwebapp appsettings set --name YourStaticWebAppname --setting-names "message=HelloEveryOne"
***Sample code for Updating App settings: ***
Before Build and deploystep in Workflow, add the below steps.
- name: Build And Deploy
- run : Your Update appsettings Script
To edit the Workflow file, click on the .github/workflow => .yml file
References taken from MSDoc 1 and 2.
Update
As per the discussion in GitHub, adding appsettings to the preview environment is not currently supported in the default Azure Static Web Apps CI/CD.
Setting appsettings on a specific environment is not currently supported in the Azure Static Web apps CI/CD nor by the Azure CLI.
There is a discussion in GitHub about it.

Azure Devops Unable to Deploy the Azure Web App throws error

I am trying to deploy the Azure Web App in the Qa instance. I have created 3 different appsettings.json files with environment specific Client ID's in it
On the release pipeline for QA branch I am trying to use the test app service and set the settings like below
Release pipeline is all getting executed without any issues but when I try to access the application URL I get error like
Application ID is still pointing to the DEV one even though the appsettings.QA.json has different client ID of the Test App Registration where I set the reply URl and all correcctly.
I am not sure why my QA release pipeline is not using the ID's from the appsettings.QA.json. Can anyone please suggest me what is that I am missing here. Any help is greatly appreciated
Check how the application picks correct appsettings.json -file into use. As it picks Appsettings.Development.json in QA-environment, check how the environment is set in QA-environment App Service. Perhaps there is an environment-variable with the value "Development" in App Service configuration and that should be set to "QA"?

How to change Azure App Services Github workflow deployment environment name

When you create an app there's no option to customize this, it's just there by default.
This matters because sometimes I don't want github actions to say that I'm deploying to "production", I want it to say I'm deploying to "development". But if I change this property manually, I'll get an error in github actions saying: Error: Deployment Failed with Error: Error: Publish profile is invalid for app-name and slot-name provided. Provide correct publish profile credentials for app. But then as soon as it's changed back the deployment works again, so I need to find a way to change this property in Azure?
Always the main slot of the webapp is called production, there is no way to change it.

How do I use the Serverless Framework in an Azure DevOps Build Pipeline without Browser Authentication?

I'm trying to deploy the simple NodeJS hello-world functions the Serverless Framework provides to my Azure free-tier account from an Azure DevOps Build Pipeline using the Service Principal credentials I created when making the deployment from my desktop originally. I've used several of the Build Agents and Tasks combinations, including Windows and Ubuntu Agents as well as Bash, Command Line, Azure Powershell, and Azure CLI tasks with the DevOps provided link to the Service Principal credentials. I've made sure to add them as Pipeline variables so that they are included in the tasks' environmental variables and I've confirmed that they are there when the tasks run. I also make sure that the Azure CLI is installed and logged into with the subscription set. No matter what settings/permissions I tweak or new configurations I try, when the task runs successfully to the point where the serverless framework attempts the deployment it always tries to get me to use a browser to authenticate my account. This obviously defeats the purpose of a CI/CD pipeline and even if I do use a browser to authenticate, the process just hangs there.
The sample code and deployment works on my desktop, so I know the credentials work. I believe I've emulated each step I take on my desktop in the Build Pipeline, yet while my desktop deploys without browser authentication the build always requests it. Does anyone have experience in this manner and know what step/configuration I'm missing?
To look at the sample code and process look here or run these steps:
serverless create -t azure-nodejs -p testApp
cd .\testApp\
Change Node Runtime and Region in serverless.yml (nodejs12.x not supported & no free tier in West US)
serverless deploy
Here's the link I used to get this working on my desktop: link
Edit: Here is the default serverless.yml created by the steps above:
service: azure-serverless-helloworld
provider:
name: azure
region: East US
runtime: nodejs8.10
environment:
VARIABLE_FOO: 'foo'
plugins:
- serverless-azure-functions
package:
exclude:
- local.settings.json
- .vscode/**
- index.html
functions:
hello:
handler: src/handlers/hello.sayHello
events:
- http: true
x-azure-settings:
methods:
- GET
authLevel: anonymous
goodbye:
handler: src/handlers/goodbye.sayGoodbye
events:
- http: true
x-azure-settings:
methods:
- GET
authLevel: anonymous
You can try below steps to run sls package in command line task to create a deployment package, and then use Azure Function App task to deploy to azure.
1,install specific version nodejs using Node.js tool installer task
_
2, install serverless using npm task to run custom command
3, use npm task to run install command to install dependencies
_
4, Use command line task to run sls package to create the deployment package
_
5, use azure function app deploy task to deploy the deployment package
Right now the Serverless Framework thinks you're trying to deploy your application using the Serverless Dashboard (which does not yet support Azure).
I'm not sure, because it haven't posted your serverless.yml file, but I think you'll need to remove the app and org attributes from your serverless.yml configuration file. Then it will stop asking you to log in.
Using the serverless framework to deploy a function through DevOps gave me the same issue.
The problem is that the sls deplopy command will build, package and deploy the code but will ask you for credentials each time you run the pipeline.
I solved this using the command serverless package in the build task, after that I deployed the zip that was generated for the command with a normal web app deploy task.

Google App Engine PHP (standard): Permissions error fetching application

Every now and then I lose the permissions for a project to be deployed via Google App Engine PHP.
HttpException: Permissions error fetching application [apps/PROJECT_ID]. Please make sure you are using the correct project ID and that you have permission to view applications on the project.
I use Jenkins, and I can see via the config history that nothing changed. Even if I escalate the privileges to "project owner" in console.cloud.google.com - same results: permissions denied.
The only way I am able to solve this issue is create a complete new app engine project.
Question: why do IAM accounts expire, and what is the recommended way of using credentials to automate deploys with Google App Engine PHP ?
I had this error message and for me the error was due to switching projects by using "gcloud config set project PROJECT_NAME" instead of "gcloud config set project PROJECT_ID".
I was able to solve it by appending --configuration CONFIG_NAME additionally to my gcloud app deploy command. I don't know why some projects work by just specifying the --project arg, and others not.
In any case it seems cleaner to always explicitly set the configuration-arg per gcloud command

Resources