I understand from experience and the documentation that bosh directors (v257+) do not enforce v2 manifests by default.
Moreover, I understand that a team admin cannot update the cloud-config.
However, when using a v1 manifest, a team admin can write a deployment manifest that overrules the cloud config. The team admin simply gets a warning Deprecation: Ignoring cloud config. Manifest contains 'networks' section.
In a setup where bosh's team functionality is used, is it possible to configure the bosh director in a way that team admins are forced to use v2 manifests and cannot ignore the cloud-config?
According to the information I got in the official slack channel, the short answer is: "no".
Related
I wanted to try provisioning my app resources in Azure using the TeamsToolkit, but it fails creating the resource group since my company requires 4 tags to be added.
Is there a way to tell the toolkit to either add those tags or create the resource group myself and make it aware of it?
I tried doing with Teams Toolkit and didn't find any option to configure the resources (choose existing or setup policy).
Following the doc also there's no mention about doing such - Deploy your app to azure and even on the market place it is not
mention that we can configure it.
we are currently using SAP BTP with global account with feature set A and are wondering - is there a way to automate user management there, creation, deletion of users etc. So far, we can do it only manually through the Cockpit UI. Found out about BTP CLI, but that one seems to work only on Feature set B. Is there some alternative for Feature set A accounts?
SAP BTP supports to use your Corporate Identity Provider for Platform Users [Feature Set A] as described here:
https://help.sap.com/viewer/65de2977205c403bbc107264b8eccf4b/Cloud/en-US/783ff50aa60a4c488f4a1e4dceee7ab9.html
Question
How can I make my Microsoft Teams connector config page look like the ones bellow?
Details
I'm creating a teams app with a connector. The documentation explain how to make our own config page. (for example here and here). It works for me 👍.
But in the app directory, I saw multiple existing connectors that share the same config page structure. (name of connector, then webhook, then instructions to install)
This structure would be good for me but I did not found how to configure my connector to use that template.
Thanks for help 😀.
I have google cloud build set up, and I'd like t away to make the builds publicly visible, to use in an open source project, a bit like how TravisCI and CircleCI offer - see an example below:
https://travis-ci.org/wagtail/Willow/pull_requests
Is this possible?
Can you make it possible to inspect a build to a non-signed in user?
A solution could be to use Google Identity and Access Management to grant the Cloud Build Viewer role to allUsers. However, this cannot be done at the moment.
The idea is to give the cloudbuild.builds.get and cloudbuild.builds.list permissions to everyone on the internet, which would allow them to call those Cloud Build API methods that require these permissions. You can grant roles to Google Accounts or Groups, Service accounts or G Suite domains, but not to everyone.
You can find detailed instructions to grant roles through the GCP console in the Cloud Build documentation.
I'm using Jenkins to produce cspkg files using msbuild. It stores build results in azure blob storage. Then I use management portal to deploy them.
The biggest drawbacks I see are:
1. Deployments can be accidentally deleted easily.
2. There is no straightforward* way to check which version the cloud service has.
Is there a better way to manage deployments?
Its definitely not the best experience is it?
The approach I tend to use is as follows:
Build the deployment package and add the version number to the package filename (taken from AssemblyInfo.cs) e.g. MyCloudService-1.2.0.0.cspkg - this should be trivial using msbuild.
Push the package to Cloud Storage.
Perform the deployment of the package from Storage, with the Deployment Label '[CLOUD SERVICE NAME]-[VERSION] # [DATE & TIME]' e.g. 'MyCloudService-1.2.0.0 # 10-09-2015 16:30'
Check the deployment package into a 'Packages' directory in source control.
If you need to identify the version of the package deployed to the cloud service, you can see the Deployment Label on the Azure Management Portal:
'Old' Portal (manage.windowsazure.com):
'New' Portal (portal.azure.com):