I'm playing with Azure Bicep and I was expecting that I can take practically any ARM JSON template and translate it into Bicep. I'm intentionally using the word "translate" instead of "decompile" here, because the JSON template was not originally created with Bicep, so it was not compiled from Bicep to JSON in the first place.
I'm creating a VM deployment in the Azure Portal and when it's successfully deployed I download the JSON template (deployment.json and deployment_operations.json).
Then I run the following command:
bicep decompile deployment.json
The command fails with the following error message:
/deployment.json: Decompilation failed with fatal error "[1:1]: Unable to find a template property named $schema."
What should I do to resolve this error?
Bicep CLI version 0.13.1 (e3ac80d678).
PS The VM deployment is the simplest possible Windows Server VM with no data disks and extra features. Created via Azure Portal by clicking Next-Next-Create.
It appears that I've found the solution when writing the question. I was downloading and trying to decompile a wrong file.
The problem was that I was downloading the deployment.json file instead of an actual template file template.json. You need to click Download on the Template tab.
So instead of downloading the from the Overview tab, click the Template tab and then click Download. Or use the Save-AzResourceGroupDeploymentTemplate PowerShell cmdlet.
Similar problem, same solution: https://github.com/Azure/bicep/issues/5237
Related
I'm trying to deploy an Azure App Service using Azure Devops.
I'm using the Task Azure App Service deploy version 4.*
I started noticing the following error in the log recently with the deployment failing (saw it first on 24th September)
Applying JSON variable substitution for **/appsettings.json
##[error]Error: NO JSON file matched with specific pattern: **/appsettings.json.
In the pipeline I use the task Extract files to extract *.zip, then use the result to search for **/appsettings.json.
The same task was running fine till a few days ago.
I tried redeploying an old release which was successful earlier, but it failed now with the same above error.
I double checked, there was no changes done in the pipeline recently for this to break.
How can I fix this.
Turns out my issue was not with the task Azure App Service deploy, but with the task Extract Files.
A rough look on my pipeline is as below:
Before the fix
Extract files
Deploy Azure App Service
The JSON variable substitution failed because the Extract files task was not able to find *.zip files in the root folder and hence extracted nothing. So, there was no appsettings.json file in the folder structure at all.
The Fix
Update the Extract files task search pattern as **/*.zip
Now my pipeline looks like below.
Extract files
Deploy Azure App Service
It now works fine for me.
I imported my Bluemix application into Eclipse. When I open it, I get a JSON error. What do I have to do to not get this error? Is there a tutorial for this?
EXAMPLE
That's not a JSON error actually. Most likely the IDE is not able to find the JSONObject class during the project build. If you leave the mouse pointer on the JSONObject class name you will read the error (actually I suggest you to enable the problems view to see all the errors: Windows->Show View->Problems).
You need to make the class JSONObject available to DemoServlet fixing the project java build path.
I guess you are using personality-insights-java. I've just tried to import it in a blank Eclipse project and I managed to build it correctly.
I am assuming that you have a local instance of Liberty server on which you want to run the application. If not see here. Go to step 2 only when you have a local working application server in Eclipse
double check that the project Java Build Path (right click on the project->Properties->Java Build Path) contains Liberty libraries (Libraries->Add Library->Server Runtime->WebSphere Application Server Liberty)
If the auto-build is not enabled, manually clean and build the project (Project->Clean)
I've been trying to follow the
Setting Up Stackdriver Debugger for Java applications on Google Compute Engine, but am running into issues with Stackdriver Debug.
I'm building my .war file from a separate build server, then deploying it to my GCE server. I added the agent to the start command via /etc/defaults, and my app appears in the https://console.cloud.google.com/debug control panel. The version I set in the run command matches the revision that shows up in the source-context(s).json files.
However when I click open the app, I see the message that
No source version information was provided by the deployed application
I connected the app's git repo as a mirrored cloud repository, and can browse the source files in the sidebar of the Stackdriver Debug page. But, If I browse to a file and add a breakpoint I get an error that the error "File was not found in the executable."
I have ran the gcloud preview app gen-repo-info-file command, which created two basic json files storing my git repo and revision. Is it supposed to do anything else?
I have tried running jetty using both normal and extracted modes. If I have jetty first extract the war file, I can see the source-context.json filesin the WEB-INF/classes directory.
What am I missing?
https://github.com/GoogleCloudPlatform/cloud-debug-java#extra-classpath mentions
you can update the agentPath showing your WEB-INF/class directory.
-agentpath:/opt/cdbg/cdbg_java_agent.so=--cdbg_extra_class_path=/opt/tomcat/webapps/myapp/WEB-INF/classes
For multiple class paths:
-agentpath:/opt/cdbg/cdbg_java_agent.so=--cdbg_extra_class_path=/opt/tomcat/webapps/myapp/WEB-INF/classes:/another/path/with/classes
There are a couple of things going on here.
First, it sounds like you are doing the correct thing with gen-repo-info-file. The debugger agent should pick up the json files from the WEB-INF/classes directory.
The debugger uses fuzzy matching to find source files, so as long as the name of the .java file matches a file in your executable, you should not get that error.
The most likely scenario given the information in your question is that you are attaching the debugger to a launcher process, rather than your actual application. Without further details, I can't absolutely confirm that, though.
If you send us more details at cdbg-feedback#google.com, we can look more closely at your case to see if we can understand exactly what's happening, and potentially improve our documentation, since it sounds like you followed the docs pretty closely.
I'm new to Azure.
I have JSON template that successfully deploys VM.
Can I add some code to JSON template to deploy this VM with rootCA. Or some syntax for AD CS deployment.
I googled a lot but there are only DSC methods.
You can't "add some code to JSON template".
Your options:
Native ARM via Keyvault:
https://github.com/Azure/azure-quickstart-templates/blob/875d139c16c9c023dce519e6dd48c707e3473346/201-vm-push-certificate-windows/azuredeploy.json
Add an extention to the ARM template.
An extention can be DSC as you mentioned, but can also be custom PowerShell for example. (see custom script extension)
Run your script after the deployment. If you run New-AzureRmResourceGroupDeployment form PowerShell, you can output the VM connection information, and manage it after. See how to configure WinRM on a created VM.
im running Hudson continuous integration for db unit.
when i run the job the console output is displaying the SUCCESS, but then why do the Parsed Console Output keep returning this error:
ERROR:Failed to parse console log :
log-parser plugin ERROR: Cannot parse log: Can't read parsing rules file:
i already installed the parse-log plugin & i already restarted the Hudson..
i installed the plugin using remote PC
any help and suggestion is appreciated. Thanks!
1) Place the Parser Rule File in the JENKINS_HOME location.
2) Configure that log parser console output in the Global COnfiguration settings and Name it.
3) Add this option in the Post Build Actions and Select the Name
ok silly me..
i forgot to configure the global configuration in hudson that link to the parser rule file..
problem solved.
I'm posting this in case anyone else has a specific case of this problem. This issue started when upgrading from 1.509.2 to 1.554.3... I had the parsing rules file in the win\system folder which was a known issue when running Jenkins as a service. Well I guess they fixed it by this version. I moved the parsing rules back into Jenkins Home folder and it worked fine again.