What is the difference between Google deployment manager UPDATE_ON_CHANGE and UPDATE_ALWAYS metadata runtime policy ? An example highlighting the difference would be very useful.
I searched through the documentation but could not find any useful references. There are a few hints on the github repository but they seem to be succinct and not verbose.
UPDATE_ALWAYS - call the API for create or update changes in the deployment
CREATE - only call on create
UPDATE_ON_CHANGE - call when the action changes
DELETE - call on deletes
This is the closest to a definition I could find.
Reference - https://github.com/GoogleCloudPlatform/deploymentmanager-samples/tree/master/examples/v2/cloudbuild
Related
I'm trying to use the TeamCity REST API to update settings against a build configuration. Specifically, the checkoutDirectory that in the UI is in the "Version Control Settings->Additional Options->Checkout directory" textbox...
The documentation talks about updating the "parameters", but not the settings.
If I do a GET on /app/rest/buildTypes/<id>, the results include both settings and parameters...
I've tried various combinations of PUT request to try to update this, but having no luck.
Interestingly, if I do a GET on /app/rest/buildTypes/<id>/parameters, I get this...
Which includes the ID in the URL.
But if I do /app/rest/buildTypes/<id>/settings, I get this...
Which doesn't include the ID. Not sure if that's a bug - or I've completely misunderstood the scope of these settings, and they're global, not per build config - but that's certainly not what I'm seeing in the UI.
Any ideas how to use the REST API to update these settings?
I am trying to find a portable way to produce code annotations for GitHub in a way that would avoid a vendor-lockin.
Mainly I want to dump annotations inside a file (yaml, json,...) during build process and have a task at the end that does transform this file into github annotations.
The main goal here is to avoid hardcoding support for github-annotation into the tools that produce them, so other CI/CD systems could also consume the annotation-reports and display them in their UI.
linters -> annotations.report -> github-upload
Tools like flake8 are able to produce output in parsable format file:line:column: message, but I need to know if there is any attempt to standardize annotations so we can collect and combine them from multiple tools and feed them to the CI/CD engine.
Today I googled up what the heck those "Github Action Annotations" are all, and this was among the hits:
https://github.com/marketplace/actions/annotations-action
GitHub action for creating annotations from JSON file
As of now that page also contains:
This repository uses npm packages from #attest scope on github; we are working hard to open source these packages.
Annotations Action is not certified by GitHub. It is provided by a third-party and is governed by separate terms of service, privacy policy, and support documentation.
I didn't try it, again, just a random google hit.
I am currently using https://github.com/yuzutech/annotations-action
Sample action code:
- name: Annotate
uses: yuzutech/annotations-action#v0.3.0
with:
repo-token: ${{secrets.GITHUB_TOKEN}}
input: ./annotations.json
title: 'Findings'
ignore-missing-file: true
It does its job well but with one minor defect. If you have a findings on a commit/PR you get to see the finding with a beautiful annotation right where you need it. If you re-push changes, even if the finding persists, the annotation is not displayed on later commits. I have opened an issue but I have not yet received an answer.
The annotations-action mentioned above has not been updated and it does not work with me at all (deprecated calls).
I haven't found anything else that worked exactly as I wanted it to.
Update: I found that you can use reviewdog to annotate based on findings. I also created a GitHub action that can be used for Static Code Analysis here https://github.com/tsigouris007/action-semgrep-reviewdog. You can visit the entrypoint.sh file and check how I piped the custom output to reviewdog utilizing jq.
I am implementing "AzureBlobStorage" by referencing "Microsoft.Bot.Builder.Azure", but when I initialize I get an error with "CloudStorageAccount".
Error CS7069 Reference to type 'CloudStorageAccount' claims it is defined in 'Microsoft.Azure.Storage.Common', but it could not be found QBotSolution
Solution Explorer:
It looks like Visual Studio can't determine which package you're trying to use. If you're just looking to do traditional bot state management, you should remove these packages:
Azure.Storage.Blobs
Microsoft.Azure.Cosmos.Table
Microsoft.Azure.Storage.Blob
Microsoft.Azure.Storage.Common
For bot Blob storage, you should only need Microsoft.Bot.Builder.Azure, so be sure to include using Microsoft.Bot.Builder.Azure; at the top of whatever file you're trying to use this in.
Here's a few good references:
State Management Sample
Write Directly to Storage - Using Blob Storage Docs
State Management Docs
I am listing my projects as follows:
listProjectsResponse, err := projectsListCall.Do()
Where a projectsListCall is a type provided by the cloudresourcemanager and its v1beta1 API.
I couldn't find a way though to be able to retrieve a the Organization a project belongs to. Is this feasible using the above api/sdk?
I am able to access the Parent field of a Project which is of type *cloudresourcemanager.ResourceId, however I cannot find a way to traverse up the tree until I reach the Organization.
What is more, I think it would be easier to find a way to say:
Given this Organization, list me all its projects.
Is there a way to accomplish this?
The Go SDK allows to retrieve that information through the methods "ProjectGetAncestryCall" and "OrganizationsGetCall". If you dig a bit in the documentation you'll see that the methods call the API endpoints mentioned by Kolban in his comment.
Moreover, whenever a doubt of this kind arises you might try searching the corresponding API endpoint in Google's documentation and then search for it in the Go SDK documentation because generally the endpoint is mentioned there.
I would like to use "download secure file" in a dev azure task - and that works exactly as expected within a task in "release pipeline" (in "Releases"). However, when I try to do the same in a "Builds" task in azure-pipelines.yml I get "file some-uuid not found".
From the official documentation I cannot find any difference if a custom task is used in "Builds" or "Releases" - it just refers to tasks no matter where it is being used -
Is there anything I can do to access one of my secure files from the library in an azure-pipelines.yml ("Builds" task) ?
I found the answer here:
https://github.com/Microsoft/azure-pipelines-agent/issues/1809
Under SOME circumstances Azure scans the 'azure-pipeline.yml' behind the scenes and when there is e.g. a request for a resource such as 'Library/secure file' or a 'service connection' is found then the appropriate permissions are set by Azure silently - so executing the build script won't run into an error.
BUT this scan for resources will NOT happen always e.g. on commit - only if the azure-pipeline.yml is created new or a variable is added or changed.
So normal editing such as write / commit of azure-pipeline.yml will not (re-)start such a scan - and if you add tasks that requires secure file or service connection later on you will experience an error saying 'file not found' or 'insufficient permissions'.
The easiest way to enforce a rescan with permission adjustment is to go to the variable tab and e.g. change the variable system.debug = false to true - or add a new variable foo = bar .
I was not able to find any of these hints or some background in the official docs - or not in a context which was helpful to relate to this problem - and as of this writing (Nov 2018) it is not clear if this is a bug or a feature - in any case it would be helpful if Microsoft could extend the Troubleshoot instructions behind this link https://aka.ms/yamlauthz which is included into the error message.
It seems that this scan-or-not-scan is specific to 'build' scripts 'azure-pipeline.yml' - that is why no such error appears in 'release' scripts.