Warning: this post contains unsupported API calls, so use at your own risk
Similar to the situation in Part 2 for onboarding a project into SonarCloud, onboarding a user into an organization is also not supported via the public API.
In the API documentation there is no entry for api/organizations
This was confirmed by a community posting and unfortunately did not appear on the roadmap:
Back to Chrome Developer Tools So in the same way as in Part 2 I used Chrome Developer Tools to monitor what happens in the SonarCloud UI when adding a member to an organization:
Warning: this post contains unsupported API calls, so use at your own risk
One of the main reasons I started looking at the SonarCloud api was to be able to automate the onboarding of new GitLab projects into SonarCloud. We didn’t want to have to do that manually via the UI, rather via a pipeline job. In part 1 of this series I demonstrated the basics of the API and the PSSonarCloud PowerShell module, in part 2 we’ll look at how to onboard a project into SonarCloud.
SonarCloud is the SaaS version of SonarQube, a tool to detect and fix issues in your code by examining code quality and security vulnerabilities. I needed to automate the onboarding of both users and code projects into SonarCloud to take away the need to manually provision these items into the system.
SonarCloud has a Web API which facilitated a lot of what I needed to achieve, however with some significant gaps which initially appeared to mean some of the onboarding would need to still be manual.
While carrying out some investigation around using the VMware Cloud Assembly API to work with Onboarding Plans we stumbled across a puzzling scenario. The documentation for creating an Onboarding Resource that is part of an Onboarding Plan shows the following content needs to be sent as part of the POST API request for the creation:
While figuring out what needed to be populated in each property I retrieved via the API the contents of existing Onboarding Resources:
For the PowerCLI book 2nd Edition I helped put together a chapter on vRealize Orchestrator. Most of the chapter was focused on running PowerShell scripts from vRO, which was something I’d had a fair bit of experience with in projects I had been on and also thought would be what most people reading would be interested in. At the end of the chapter I added a few functions using the vRO REST API to run things in vRO from PowerShell as a bit of an after-thought.
I like the new Swagger UI for the vRO API, it makes it really easy to use:
While using it to figure out some stuff around importing a package, I hit an issue with the tagImportMode parameter:
Depending on which option selected, the following additions to the URL were listed in the documentation as follows:
https://vroserver.fqdn:8281/vco/api/packages?overwrite=false&importConfigurationAttributeValues=true**&tagImportMode=Do%20not%20import%20tags.**
https://vroserver.fqdn:8281/vco/api/packages?overwrite=false&importConfigurationAttributeValues=true**&tagImportMode=Import%20tags%20and%20overwrite%20existing%20values.**
https://vroserver.fqdn:8281/vco/api/packages?overwrite=false&importConfigurationAttributeValues=true**&tagImportMode=Import%20tags%20but%20preserve%20existing%20values.**
However, none of these choices seemed to work, just resulted in 400 (Bad request).
There is an excellent post over at Automate-IT.today which details how to create a vRA IaaS Blueprint from vRO. Once you have used the workflow from that site to create a Blueprint it still needs to be published before it can be used as a vRA Catalog Item, added to a Service etc.
Note that even updating Christiaan Roeleveld’s code to set the property IsPublished to true, doesn’t actually publish the Blueprint.
It’s pretty disappointing to need to do this, but recently while working with vCNS / vShield 5.5 and automating it via the REST API I have been making extensive use of the vShield 5.5 API Programming Guide. On the whole its a decent document with lots of useful examples, without which I would have been struggling.
However, there are numerous mistakes in it, particularly around the URLs required for various API calls.