In description of Google Cloud Build app on GitHub here https://github.com/marketplace/google-cloud-build every build seems to be identifiable by name:
Cloud Build Triggers With Names
In my current set up, however, every build is displayed by id, which is not very useful:
Cloud Build Triggers with IDs
Is there something I am not doing to make it work as expected?
When I think about Cloud Builds, I understand that every individual build has a unique identifier. For me, this is what I would want to see in a report of a build being triggered. Given a Cloud Build ID, I can then use that for visibility into the underlying process that unique instance of the build caused. I can see all the steps and the outcome of each of them. I couldn't imagine wanting anything else than a build identifier being reported to me as a result of a Cloud Build being performed.
References:
Viewing build results
I posted the original issue in the issuetracker in January 2020,
This is not since fixed and identified real names since August 17th. You do have to reclick on the new names if you have made any previous hash based ones required steps in your build.
For any triggers created prior to August 2020, data sharing needs to be enabled for this to work, As documented here:
https://cloud.google.com/cloud-build/docs/automating-builds/create-github-app-triggers#data_sharing
You need to go in the Settings -> Data Sharing section of cloud build and enable it
In some cases you might get a Failed to enable trigger data sharing error when trying to do this, if so you might want to try
1 - Disable any required checks you have in github related to cloud build
2 - Try doing it using chrome without any ad blocker, for me it wasn't working using Brave browser but worked with chrome
This will allow github to show the trigger name instead of an id in the pull request checks
Related
I have been working on a project in which i need to track the build time of the application when i make a commit. How can we push the build time data to a server ?
Reliza Hub (disclaimer I'm working on the tool) - provides build time analytics among other things. Just setup project per Getting Started guide here - https://docs.relizahub.com/guide/#description (this one already uses GitHub Actions).
Here is sample GitHub Actions integration script for docker images which includes sending build time data: https://github.com/relizaio/reliza-hub-integrations/blob/master/github-actions/dockerBuild.yml
In theory if you modify the script, you could similar data to your own platform such as ELK.
One note though that build time in this case does not include the time it takes for GitHub Actions to set up build environment.
After setting everything up you would get build time analytics chart in the project analytics which looks as following: https://i.imgur.com/uCn3QKP.png
Alternatively, you can stream build time metadata elsewhere (suck as ELK) using similar principles as in sample integration yaml referenced above.
I'm running TeamCity Enterprise 2019.2.4 (build 72059).
Is there an easy API call to get the username of a person who disabled a build step?
If that is not possible, as I suspect, what's the API endpoint to get a list of all modifications for a build configuration, and then the endpoint to get the contents of that modification?
Mind you, this is not about VCS changes. I know how to get those.
I enabled versioned settings for that project, so I just check the git history for the file that represents the build configuration and parse the commits for the one that disabled the build step.
I'm currently using Heroku Pipeline feature for automatically detecting, building and deploying pull requests for review.
✓ Create new review apps for new pull requests automatically
URL pattern
Pattern: Random pipeline-xxxxxx-xxxxxx.herokuapp.com
The problem is that my app needs a combination of 2 buildpacks in a specific order in order to boot properly.
The main/production app has this settings and it works fine(e.g. after each time a PR is merged).
From what I see Review Apps doesn't have a concept of buildpack settings and it tries to autodetect it each time.
What I've tried:
Open the latest Review App, set buildpacks, rebuild or push a new commit. It works fine in that Pull Request/branch/Review App but for each new PR this process has to be repeated manually.
Is there any way to overcome this issue?
In case you have a similar issue, one approach that you can use(that worked for me)
app.json Heroku's convention file where you can list your buildpacks among many other settings.
I'm trying to deploy an existing build with the "LabDefaultTemplate.11.xaml".
My problem is, that the build times out, as soon as I use an existing build. Here are the last steps including details and the timeout exception:
See http://i.stack.imgur.com/po1i6.png
I have two different servers. The first has TFS 2013 with Build Service, Controller and Agent installed on it. The second is thought to be used for Testing and has a Test-Controller and Agent on it (configured as a Standard-Environment in MS Test-Manager).
Build Service Account is a Domain-Admin
Build Connection to TFS goes with a TFS-Admin
Test Controller Service Login Account is a Local-Admin (mirrored on the Build-Server) and earlier tried with the Domain-Admin
Test Controller TFS-Connection also with a TFS-Admin
Test Controller Lab Service Account is not used, earlier also tried with the Domain-Admin
When I set the build to use the latest TFS-Build it runs into the timeout.
And when i set the path to use a Build from a specific location to the Build Directory on the Build-Server it all just works fine.
The difference between a working build and the timeout described above can be seen in this picture: http://i.stack.imgur.com/gPM07.png
Has anyone an idea where I'm struggling?
The problem was, that my previous builds only "partially succeeded" because they had some failing unit tests. The setting to use the only uses fully successful builds. So the latest build which was used had no drop folder configured.
I received no info about that, until I saw it in the logs. My fault was to never check, which build really is used as the latest.
I have a Build & Deploy Pipeline in Bluemix, I would like to create a condition where, if the build fails, it will automatically assign a defect (i.e., work item in the "Track & Plan" page) to whoever delivered the very latest change (or just assign to the main owner of the App/Project), also, if the build is completed successfully, I would like to tag it.
Tagging is ok, that's general GIT knowledge, I just wanted to solve 2 Problems with that plan:
How do we trigger a specific subsequent Stage in the pipeline if the current build fails/passes?
How do I create a work item from the pipeline? Do I need to create a separate GIT repo and build some sort of API package that allows me to invoke a mechanism that creates the ticket?
I guess I'm going too maverick with this Pipeline, please share your thoughts.
As of right now you can not create a work item from the pipeline. That is a great feature improvement and I can take it back to the team.
For your question about triggering a stage if something passes or fails... The way it works now only the next stage will be triggered if the previous is successful. The pipeline is based on Jenkins and Jenkins doesn't allow you to trigger a specific job if a job passes or fails. You would want to detect the pass or fail in your stage and do your logic based on that.