So I need to make automation on nodejs application on GCP.
The idea is, I need to deploy the web app (nodejs) with cloud run but every time a developer
did push on Github the image should be rebuild and deployed automatically. The constraint is that I need to use webhooks to send me notification that a push is done.
Can some of you give me some directions or steps how to make this work?
It might be worth to try Cloud Build.
There is possibility to build with node.js (Node.js Build).
There is possibility to deploy in Cloud Run (Deploy with Cloud Run).
Finally there is a possibility to setup trigger on GitHub push (GitHub triggers).
I think that even this webhook constraint is not needed in this case... However there is push notification feature as well.
Related
Greetings from Brazil!
I have an app in github which I am deploying to a cloud service. I want to deploy this same app to other services such as Heroku, AWS and/or IBM Cloud, using Github diff changes (i.e. when I update the repo it automatically updates the cloud app - like magic). Currently GitHub diff changes works fine with streamlit share and heroku, but I have separate repos.
My questions is that: can I deploy an app to multiples services from just one repository in GitHub?
Irrelevant for the question: currently the app is Python3 and I share the app in streamlit share and Heroku, using separate repos. My question, however, is app agnostic.
You can use GitHub Actions to define your deployment workflows.
You can deploy to various cloud providers using available actions/operators:
Amazon ECS
Azure
Heroku
Your project can define a workflow for each cloud provider and, within each workflow, decide when the deployment occurs (automatically on every push, only selected branches or manually - pushing a button).
Our App Center 'Build on every push' is not working. When I merge a PR in Azure DevOps and refresh App Center it shows the new commit but never triggers a build even though the build is configured to do so. This issue reports the same issue, but doesn't offer any resolution.
In Azure DevOps I see two service hooks configured for App Center (both created by an ex-employee). When I try to test those hooks, both return a 404 error from App Center. I can find no documentation on how service hooks between Azure DevOps and App Center should be set up.
Is there some way I can disconnect the service hooks and re-create them?
Is there some way I can disconnect the service hooks and re-create them?
The answer is yes.
You could go to the Project Settings->Service hook, select the service hook for App Center. You could delete it, then create a new service hook:
If you could not delete it, please check if you have permission to delete the service hook.
Update:
Since you want to create a service hook, you could configure it as follows stpes:
Select Azure devops as service on the Build tab:
Sign in with your Azure devops account and select the project you want to build.
Make sure the option Build this branch on every push is select:
Then, we could submit any change in that project in azure devops repo, the build in app center will be triggered. We could also check the service hook:
Hope this helps.
I contacted App Center support using the chat button in the lower corner. They did a soft reset on the projects on their back end and the existing service hooks started working.
Not sure could I have fixed the issue without support, as I didn't try recreating the service hooks myself.
Basically I just started using Google Cloud and I'm looking for a way to trigger a deployment ONLY when a pull request is accepted on a distant github repository.
I'm currently using the google "Cloud Build Trigger" to execute my 'cloudbuild.yaml' as soon as a push is detected on my master branch, but simply attempting a merge request seems to trigger my build process.
This is troublesome as a merge request will be reviewed by peers and I don't want my cloud application to rebuild if the merge request is to be denied after being reviewed.
As this feature is still in beta, I assume this is not supported yet and that there is a better way to handle such task, but when I heard of the trigger feature it seemed like the most straightforward way to connect my github repository to the build process on google cloud. Anyway, hope someone had to face this issue or can help me figure this one out.
Thanks !
Based on the documentation, Cloud Build triggers currently only support changes pushed to the build source (a remote Github repo in this case). There doesn't seem to be a way to distinguish between a merge resulting from a (remote) pull request or a local one from the Google Cloud Console GUI.
However, you are not without options. One alternative is to leverage Github's PullRequestEvent Webhook and deploy a GAS Web App or Cloud Function to serve as a web-hook endpoint. The GAS Web App or Cloud Function could then parse the event payload for GitHub's PullRequestEvent and if the pull request is closed and merged then you call the REST API for the Cloud Build service to start your build.
We installed the Google Cloud Build GitHub app. We then created some Build Triggers with the Google Cloud Build web user interface. This worked for a while.
Recently we pushed new branches to our GitHub repositories and tried to create Google Cloud Build Triggers for those branches. The Trigger Settings page says "No branch matches" even though we are 100% sure that the branch exists on GitHub.
How can we refresh the branch listings in the Google Cloud Build Trigger Settings page?
We have tried logging in/out of Google Cloud Build and GitHub. We have also tried uninstalling and re-installing the Google Cloud Build GitHub app. We have also tried simply waiting for a few hours.
The problem was that, while configuring Cloud Build with GitHub, we had pushed too many buttons.
This is an overview of what we needed to reset.
In GitHub
Go to the affected repository.
Open its settings.
Delete the Webhook associated with source.developers.google.com/webhook/github.
Delete the Deploy key associated with Google Connected Repository Fingerprint.
In Google Cloud Console (console.cloud.google.com)
Open Source Repositories
Disconnect the mirror of the affected repository.
Open Cloud Build
Delete and recreate the Build Trigger(s) for the affected repository.
Aside re: the Google Cloud Build GitHub App
Setting up specific triggers in Google Cloud Build is orthogonal to using the Google Cloud Build GitHub app. The former does not require the latter. They are different ways to do similar things.
If you had installed the Google Cloud Build GitHub App in your GitHub account because you thought it was required for Google Cloud Build Triggers, then uninstall the Google Cloud Build GitHub App. It works differently than setting up specific Google Cloud Build triggers does, and I found it quite confusing to have both running.
I want to deploy a liberty application along with server config to Bluemix, I found these options listed in the documentation
https://console.bluemix.net/docs/runtimes/liberty/optionsForPushing.html#options_for_pushing
My question is should we be pushing the app + server always to keep the server config, or it like push app + server for the first time and subsequent pushes can only contain app files ? will the server config be retained?
You need to push the app + server every time.
There are a number of ways to deploy Liberty on the IBM Cloud - the recommended place to get started is on the App Service console:
https://console.bluemix.net/developer/appservice/starter-kits
The documentation has options for Kubernetes / CF Deployment to the Cloud and recommend using the IBM Cloud Dev CLI tooling which containerizes your app to run locally and gives you the option to push the image up when you're ready.
In addition, starter kits set up an example of how you can incorporate DevOps into your app. When you make changes from your Git Repo, it will trigger a hook which will run the app through your testing pipelines, and deploy it to the cloud.
The idea of using containers is so you can package your application with a consistent, reproducible environment, so you can orchestrate and scale your application when necessary.