I have been trying to integrate Google Cloud Build with my GitHub account. I have set up working build triggers in the past for other projects on GCP - but with this one, I just can't get it to work reliably. Here is what I did:
Install the Google Cloud Build App on GitHub and link it to my Google Cloud Account.
Connected to my GitHub repository in Google Cloud Build. As source, I selected "GitHub (Cloud Build GitHub App)".
Let Cloud Build create its default trigger for me - just to make sure that the settings are correct.
Now, when manually running the default trigger, I always receive the following error message after selecting my branch: "Failed to trigger build: Request contains an invalid argument." Here is what that looks like:
The trigger also does not work when invoked through a new commit in the GitHub repository. There are two different errors I have spotted through the GitHub UI:
The GitHub Cloud Build Action essentially reports the same error as Cloud Build itself when manually invoking the build and immediately fails:
The GitHub Cloud Build Action is queued/started, but never actually does anything. In this case, Cloud Build does not even seem to know about the build that was triggered by GitHub. The action will remain in this state for hours, even though Cloud Build should usually cancel builds after 10 minutes by default.
Here are some things that I've tried so far to mitigate the issue:
Create all sorts of different trigger variations - none of them seems to work. The error is always the same.
Uninstall the Cloud Build App on Github, unlink my Google Cloud account, and go through the entire setup process again.
When connecting the repository in Cloud Build, instead of selecting the GitHub App as a source, select "GitHub (mirrored)".
At this point, I seem to be stuck and I would be super grateful for any advice/tip that could somehow push me in the right direction.
One more thing that I should note: I have had the triggers working for a while in this project. They stopped working some time after I renamed my master branch on GitHub to "production". I don't know if that has anything to do with my triggers failing though.
I found that this can be caused when you have an "invalid" CloudBuild config file (e.g. cloudbuild.yaml).
This threw me off, because it doesn't necessarily mean it is invalid YAML or JSON, just that it is not what CloudBuild expects.
In my case, I defined a secretEnv value, but had removed the step that utilized it. Apparently, CloudBuild does not allow secretEnv values to go unused, which resulted in the cryptic error message:
Failed to trigger build: Request contains an invalid argument.
In case that isn't clear, here is an example of a config file that will fail:
steps:
- name: "gcr.io/cloud-builders/docker"
entrypoint: "bash"
args: ["-c", "docker login --username=user-name --password=$$PASSWORD"]
secretEnv: ["PASSWORD"]
secrets:
- kmsKeyName: projects/project-id/locations/global/keyRings/keyring-name/cryptoKeys/key-name
secretEnv:
PASSWORD: "encrypted-password"
UNUSED_PASSWORD: "another-encrypted-password"
UNUSED_PASSWORD is never actually used anywhere, so this will fail.
Since this error message is so vague, I assume there are other scenarios that could cause this same problem, so take this as just an example of the type of mistakes to look for.
Related
I'm collaborating on a website using Github for source control. The site is hosted on a shared server on Dreamhost. I'd like to set up an easy way for myself and my collaborator to be able to see changes that have been merged into the main branch on the staging site then also run a couple of other shell commands (composer update, for example, after deploying the changes).
I'm new to this. I've found pieces of relevant documentation but have not been able to tie it all together. So far I am running into at least two issues.
Setting up github environments to point to development and staging environments
I looked into Github Workflows but it seemed Github Actions might be easier. I set up Github Environments called staging and development. When setting up the environments, I saw the option to add environment secrets but don't know what exactly to add here. So my environments in Github have names but don't really point to my development and staging environments. I think the first thing I need to figure out is how to link my Github Environments and actual development and staging environments together. I found Deploying with Github Actions but didn't find an answer there.
Invalid workflow file error
Also I found an action in Github Marketplace called branch-deploy. I created a yaml file under .github/workflows to test it. When this runs, I see an error on the workflow in Github of
Invalid workflow file
The workflow is not valid. .github/workflows/deploy.yml (Line: 2, Col: 1): Unexpected value 'id'
Not sure what is going on with this error because the "basic usage" example in the Marketplace page uses the same value for id.
I'm doing Visual Studio builds on a self hosted agent, which are currently being triggered by the Continuous Integration setting in an Azure Devops pipeline.
When a build completes, it shows: Triggered by Microsoft.VisualStudio.Services.TFS
It also shows the repository, branch and revision number.
However, it is expected it would show Triggered by , If not showing the correct Azure Devops user, at least showing the Subversion user name, that would be something.
There was an expectation it would be possible to send email notifications to the user of the commit. (Not fool proof that they caused the problem, but the most convenient way to give the responsibility to somebody to make sure any build error gets resolved)
Does anybody know if a solution exists?
In both Classic and yaml pipelines, you can specify a condition for a pipeline step. If you want it to run when the pipeline fails, it will be condition: failed() (in yaml), or Control Options -> Run this task -> Only when a previous task has failed (in Classic). Alternativel, you can check Agent.JobStatus variable.
there's no predefined variable for current committer, but you can easily determine the last commit's author by using svn command, then log it. (any other version control system will have its own CLI that should allow it).
In yaml, it could look like this (using git instead of svn):
steps:
... (your build)
- bash: |
author=`git log -1 --pretty=format:'%ae'` # get last commit author from git
echo "last commiter: $author"
# TODO: send email or other kind of notification
condition: failed()
In classic one:
You are using wrong tool for you task. CI build will be triggered after changes was committed to branch. In that case it is not possible to fix those changes. As a result you will have history where a lot of revisions are not stable.
It might be more suitable for you to use PR policy build. It is designed to validate incoming changes so target branch will be always stable and ready to some deploy. In this case, policy build will be triggered by PR creator so he will be informed about it's result. That can be configured in personal notification settings.
In the end I couldn't Continuous Integration triggers to reliably work. They would always stop working after a short time. I'm surprised I have ran into so many issues with this, but I guess it just isn't that well supported.
Instead, now, I am queue the build via an svn post-commit hook which uses the azure devops REST API.
the REST API has setting, requestedFor":{"id":""}, where you can add the user id (which I also needed a rest api command to find)
A lot of messing around to get to this point, for a feature I expected to 'just work', hopefully this keeps working
I'm struggling to get a Google sample working.
I think I'm following the instructions correctly but now, when testing (in project-y), I receive a warning:
You are testing the Actions that you have created in project: project-x
I had previously used project-x but it has since been deleted. I've tried deleting the project and recreating, redeploy etc. but I'm entirely unable to avoid the error.
I'm unable to determine where project-y references project-x and how to correct this.
The only location where project-[x|y] are referenced is in ./sdk/setting/setting.yaml:
defaultLocale: en
localizedSettings:
developerEmail:
developerName:
displayName: Updates sample
fullDescription:
privacyPolicyUrl:
pronunciation: Updates sample
shortDescription:
smallLogoImage:
termsOfServiceUrl:
projectId: project-y
When I gactions push and gactions preview deploy, both commands correctly reference project-y and the generated URLs correctly point to project-y:
gactions push
Pushing files in the project "project-y" to Actions Console. This may take a few minutes.
Sending configuration files...
gactions deploy preview
Deploying files in the project "project-y" to Actions Console for preview. This may take a few minutes.
Sending configuration files...
I've scoured the gactions config and the cloned directory for hidden configuration files but am unable to find any references to project-x.
If I search, the only reference I find is the single reference to project-y in the above YAML.
I have seen the same issue.
In my case, it is because I used the same Display name for project-x and project-y.
I hope you check your project's Display name on Develop tab in Actions Console and solve your issue.
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...
Regards,
Your help will be appreciated.
I have created a pipeline in VSTS\Azure-DevOps. It gets its sources from a repository in Bitbucket. Queueing a build works fine. It builds and the tests succeed.
Now I want a build to run on every commit to the repository on Bitbucket. However, when I edit the pipeline and in the Triggers tab enable 'Continuous Integration' and click 'Save' I get the following error:
Unable to configure a service on the selected Bitbucket repository. Bitbucket returned the error 'Forbidden: '.
I am confused that I get 'Forbidden', while getting the source-code already works.
What is it that I am doing wrong? Is there something I must configure in VSTS\Azure-DevOps or in Bitbucket?
Answering my own question:
It appeared that in Bitbucket I only had the rights of 'Writer' for the Repository. When we changed it to 'Administrator' enabling Continuous Integration worked and we verified that committing a code change triggered the build.
Good news / bad news.
It looks like - for now - you can configure a pipeline without being a BitBucket admin on the repo... but not using the templates.
So you can build an empty pipeline based on a BitBucket repo (no admin access), and manually add each of the tasks.
Based on further tests: what you cannot do is set the Continuous Integration trigger, because that requires admin access to set up the webhooks
I know, this is not what you want... but at least there is a way to end up with a working pipeline.
Regards,
Jose