Currently using terraform = 0.11.14 and azurerm provider = 1.29.0. Where can I find the required powershell modules / versions for my current azurerm provider version?
For example is Az.Accounts 1.6.0 ok for my current azurerm provider or do I need an older version?
Windows 10
Powershell 5.1
I am not aware that there is the required PowerShell modules/versions for the current Azure provider version. It's recommended to use the latest Azure PowerShell module version. If you're interested in the Azure provider's latest features, you could check out the changelog for version information and release notes.
For the error in your comment, it indicated that your existing PowerShell session is "locking" the module by loading possible elements from it. Since local-exec provider invokes a process on the machine running Terraform, not on the resource. When you run it in terraform, it actually runs on local PowerShell. I don't think it will be related to the terraform version. This error might be due to your existing PowerShell session. You could exit it or open a new PowerShell session. Refer to this.
Hope it helps.
Related
I am using TFS 2017 and recently added RHEL Linux build agent with docker installed on it, but when I am trying to queue docker based build on this agent I am getting below error
Issues with deploy phase 'Run on agent' - No agents could be found that match the following demands (queue: 'DockerLinuxRHEL'): DotNetFramework
I have also tried removing it from build definition, but it's greyed out.
Is there a way to remove this default demand because this agent is just for docker stuff I don't want to install anything else?
It because you have a task that required .Net framework installed, like PowerShell, MSBuild, etc.
When you will remove the task the demand will be removed.
How to remove default demand DotNetFramework from TFS agent?
I am afraid we could not remove the default demand DotNetFramework.
Just like Shayki said the demand comes from the powershell task itself. So, if we want use the powershell task, we have to install the Net Framework on Linux machine.
However, it's not recommended to build .net framework projects in Linux environment. Usually we use mono with reference assemblies and the dotnet cli to do that.
More details please refer to this blog and the discussion here.
So, remove default demand DotNetFramework or install Net Framework on Linux machine is not a viable option.
To resolve this issue, we could use the PowerShell Core task:
- pwsh: # inline script
workingDirectory: #
displayName: #
failOnStderr: #
errorActionPreference: #
ignoreLASTEXITCODE: #
env: # mapping of environment variables to add
Note: pwsh runs PowerShell Core, which must be installed on the agent or container.
Hope this helps.
How can I determine what version of the declarative pipeline syntax is available to me when writing a Jenkinsfile if I do not have the permissions needed to list the plugins in the Jenkins server?
I am trying to write a Jenkinsfile using the declarative syntax, but cannot tell if the errors I encounter are because I am misinterpreting the documentation or if I am referencing documentation for a newer version than available on the box.
I have access to Jenkins server to configure and run a build. However, I have no management or script permissions over Jenkins itself, so none of the options on How to get a list of installed jenkins plugins with name and version pair? worked for me.
Perhaps there is a way to make my Jenkinsfile echo the relevant version information as part of its execution? Or some easy syntax tests that (based on pass/failure) would prove which syntax version is available?
This might be helpful, depending on version of Jenkins, but a note at the bottom said this was blocked more than a year ago. So there probably isn't a way to do it without admin access. You can use the REST API, CLI, or script console, but all fo these require admin access.
https://support.cloudbees.com/hc/en-us/articles/218756317-How-can-non-admin-users-view-the-installed-plugins-
I am trying to build my packages using TFS, already integrated with octopus server so that the package can be pulled to octopus server afterwards and get deployed automatically.Created a build definition to build db and windows packages. it goes successful for db however stuck in case of windows where it is supposed to create a release for its deployment.Error -:
There was a problem with your request.
- Release '20170808.12' already exists for this project. Please use a different version, or look at using a mask to auto-increment the number.
Error from Octopus server (HTTP 400 BadRequest)
Could anyone please help me on it....
Thanks in advance !!
You are attempting to a create an Octopus Deploy Release with a name which already exists.
You could adjust your version strategy through AssemblyInfo.cs or adjust Octopus Deploy to not use package names for Releases for under Octopus -> Project -> Settings
Please check if the Release '20170808.12' already exists.
According to the description in this article, it should be an Octopus Deploy issue.
Which version of Octopus Deploy do you use? If you are using the old version, just trying update to the latest version.
In addition, you can try to use below Create release options to check if that works:
--ignoreexisting If a release with the version number already
exists, ignore it
--force [Optional] If a project is configured to skip
packages with already-installed versions,
override this setting to force re-deployment
(flag, default false).
Also try to create a release with a specified release number:
octo create-release --project HelloWorld --version 1.0.3 --server http://octopus/ --apiKey API-ABCDEF123456
See creating-releases for more information.
Using csx scripts in Azure Functions I can use the Project.json file to install nuget packages, but when I'm using fsx scripts the packages aren't installed (the log console never shows the Starting NuGet restore message). The only way I found is installing locally and uploading the dependencies. Am I missing something?
I think that the current execution model for F# in Azure functions does not support project.json. There is a work in progress PR to improve F# support that will enable this.
For now, I think there are two options:
Install the packages locally and upload them to Azure (as you are doing)
If you're deploying via git, then I think the deployment lets you run deployment script (in the same way in which Azure WebSites let you run a deployment script).
I have not tested the second approach with Azure functions, but I think it could work. For example, see the F# Snippets' deployment script which calls a build script that starts by using Paket to restore dependencies. This way, you need just paket.bootstrapper.exe and paket.dependencies with paket.lock to specify your NuGet dependencies.
I've set up Jenkins as a service on my Windows 7 developer PC in order to provide rational arguments to why we should use Jenkins and not Bamboo in the company.
I've installed the 'Analysis Collector Plugin': https://wiki.jenkins-ci.org/display/JENKINS/Analysis+Collector+Plugin, but Jenkins ignores my configuration of the trend graph:
After I save the config, it still displays the default graph with the default settings:
I know the graph settings are stored as cookies, which is why I use the URL http://127.0.0.1:8080 instead of http://localhost:8080, but still I can't get it to display the right graph.
Jenkins v1.538
Static Analysis Collector Plug-in v1.38
This issue has since been resolved in later versions of the Static Analysis Plugin. Please download and install the latest version 1.51 and upon restart the issue should be resolved.
There is an interdependency of this plugin with the Static Code Analysis Plugin, so you will need to update that plugin to the latest version as well.
Lastly, and most importantly, you will need to (and should anyway) update Jenkins from version 1.538 to a more recent version to remain compatible with the newest version of the Analysis Collector Plugin. For this reason (as well as many others), I highly reccomend the latest version of Jenkins as well, which at the time of writing this is 2.63.