Is there any way to trigger a Google Cloud build ONLY when a merge request is accepted on a specific branch? - github

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.

Related

How do I Cancel Github Check Queue for GCP Cloud Build?

I was experimenting with cloud build in Github. Im not sure why but the github check keeps getting hung up in the queue and it doesnt seem to ever timeout. I have no way of canceling it.
I have already:
Closed the PR
Disabled then deleted the trigger
Disabled the cloud build api
Removed the cloud build integration from github settings
Removed any of the protected branch setting for checks
I'm not sure what to do next. I dont think I will be charged from GCP as there is no activity coming from the cloud build api logs. Perhaps there will be a charge from Github?
Does anyone know how to cancel this check or at what point it will finally timeout?

Automate mirroring GitHub to GCP Source Repository?

We run Google Cloud Functions (python), which require to be deployed from Google Cloud Source Repository. Since all the code is stored on GitHub we resort to first mirroring GitHub into Source Repository. Although this only requires a few mouse clicks, it becomes a burden to repeat over 3+ projects (dev, staging, production) times 5+ repos (5+ apps).
I am looking to automate the mirroring config, preferably to add into the Terraform automation we already use, into a hands-off project configuration. Does the Google API support this mirroring automation? So far on my Google Cloud expedition everything was available in their API!
I fail to find Terraform examples though, and would appreciate a tip.
Come to think of it, if I can take Source Repository out of the equation, that would be just fine with me too. After all, I only use it as a pass-through / empty shell.
The Cloud Source Repository API includes a Repo resource that has a Mirror Config object where you could type in your Github's URL, webhook and credentials to automate this procedure. I would initially test it with the create method, but if you have an existing Cloud Source Repository I believe the patch method will also be worth exploring.
Additionally, there is an open Feature Request in order to connect a repository via the Cloud Build GitHub App that I recommend you to star and follow, as it could further ease your automation needs.

GitHub Google Cloud Build - Multiple Repositories

I'm interested in trying the Google Cloud Build continuous integration application on GitHub.
My application currently has 2 repositories I would like to deploy in a single Docker image. One of them is NodeJS API server, the other is a browser-based (no server side rendering) ReactJS application.
The idea would be to have the NodeJS repo serve requests under /api/... and any for any other URIs, it would serve up the React app.
My question, is it possible to have the Google Cloud Build grab another repo as well, as long as it's on GitHub? Ideally, a commit to either repo (in the right branch) would trigger the same underlying build. Just curios if this is possible.
One approach would be for GitHub Google Cloud to grab a third repository, which would be a "parent" repo referencing the right SHA1/branch of your two other repositories as submodules.
You can see an example of such a build in "Static Website with Hugo, Cloudflare and Automated Builds using Google Cloud".
That would allow you to still work with "one" repository, even though that would check out two others in their own subfolders.

Google Cloud Builds Trigger for GitHub Repo says "No tag matches" Always

Build Trigger Setup
Setup a Build Trigger to a GitHub Repo
Trigger Type: Tag
Tag(regex): .*
Cloud Build Configuration file
Substitution variables:
_DEPLOYMENT_ENV: staging
The config is below:
Things I've Looked at
I've checked out the GitHub Applications and Authorizations. Google Cloud Platform is approved
The Google Cloud GitHub Marketplace Plugin is on for the repo and functions. I get a greencheck mark on pull requests after it builds the containers
Current Results and Expectation
I expect there to be tags matched because the repo has some tags. I push some new tags and nothing has changed.
Note: Google Cloud Build's GitHub Marketplace Plugin is still in Alpha, so its features are not reliable and it is not unusual to run into breaking changes... and there is no active support for it.
The screen you are seeing is from Google Cloud Platform -> Cloud Build -> Triggers. It is different and unrelated to the Google Cloud plugin found inside the GitHub Marketplace (I know, it is confusing).
The triggers you setup currently pull in GitHub repos into Google Cloud Source Repositories before your triggers are executed.
The GitHub plugin, I have been having some issues with it these few days and I think they are introducing some new breaking changes on it soon, but when it worked, it does not require any triggers and purely looks at the cloudbuild.yaml file to do builds automatically. I had to create separate scripts inside the cloudbuild.yaml to setup different build based on tags / branches (Cloud Build Triggers let you do all these inside the UI), but what you get as part of the GitHub plugin is this "GitHub Checks Events" (the green check / red cross) next to the corresponding commits in GitHub and also a very brief details page. The GitHub plugin is currently acting weird on me and I am in the process of switching over to use Cloud Build Triggers until they have sorted it out.
I think they are working on something to bridge the difference between Google Cloud Build Triggers and the Cloud Build GitHub plugin... just a feeling from the current log messages I see inside Cloud Build...

Service Hook of Pull Request created is not being triggered when Pull request is created through Team Services REST API

I'm trying to integrate my Visual Studio Team Services with Slack, and the first thing I tried to do was notify my Slack channel whenever a Pull request is created.
So I searched through the options, and the best fit so far was the Service Hooks available on Team Services, which integrate seamlessly with Slack, or does it?
The problem I encountered was: I use a tool that creates pull requests through the REST API, and the service hook doesn't seem to be working when I create pull requests through this method, only when using Team Services UI.
This is the Service Hook configuration.
Has anyone faced the same problem, or know any other way of notifying a pull request creation to slack?
Apparently the issue has been fixed by Microsoft, the last update of Team Services triggers the event without a problem now.