I have been working on Terraform using AzureDevOps before that I developed tf files using VS code and everything worked fine when try to move files from VS code to Azure DevOps , getting issue on Archive source file path it unable to find the directory, searched every where but unable to resolve this,
Path which was working fine on VS code was “…/Folder name” using same path in Azure DevOps as I have upload completed folder that I have build in VS code but it always get failed when try to archive files as it un-able to find the directory.
[Code Block DevOps]
terraform {
required_providers {
azurerm = {
source = "hashicorp/azurerm"
# Root module should specify the maximum provider version
# The ~> operator is a convenient shorthand for allowing only patch releases within a specific minor release.
version = "~>2.11"
}
}
}
provider "azurerm" {
features {}
#skip_provider_registration = true
}
locals {
location = "uksouth"
}
data "archive_file" "file_function_app" {
type = "zip"
source_dir = "../BlobToBlobTransferPackage"
output_path = "blobtoblobtransfer-app.zip"
}
module "windows_consumption" {
source = "./modules/fa"
archive_file = data.archive_file.file_function_app
}
output "windows_consumption_hostname" {
value = module.windows_consumption.function_app_default_hostname
}
Image of VS Code where everything is working fine:
Image of DevOps where getting Missing Directory Error:
Folder Structure that is working fine with VS code
It was due to path which is fixed now,
Related
I have been trying to fix what seems to be a path resolving issue while running Terraform. The issue I notice is, the ${path.cwd} is resolving to /terraform path and not the actual path in which the .tf files and the output.tf files exist. I have tried hardcoding the path, but, what I see error related to the file not being available in that path as well. How to list out all the files in path.cwd to help with debugging if it is possible? What could be causing this?
output {
value = templatefile {
"${path.cwd}/somefile.yml" {
x = a.b.c.something.id,
y = c.v.b.something.id
}
}
}
With Terraform I am trying to create a directory inside Repos, with a repository.
resource "databricks_directory" "test_directory" {
path = "/Repos/test123"
}
resource "databricks_repo" "test_repo" {
url = "https://somegiturl.com"
path = databricks_directory.test_directory.path
# Other variations tried:
#2 path = "/Repos/test123"
#3 path = "${databricks_directory.test_directory.path}/"
#4 path = "/test123"
branch = "main"
}
The first resource successfully creates the test123 folder inside Repos.
The second resource states for path option 1, 2 and 3:
Error: Invalid repo path specified
Option 4:
Error: Repos can only be created in the /Repos folder
Apparently I am missing something... How can I successfully place the repository inside the test123 folder?
Okay, so apparently you need to put the repo as a folder inside the directory.
So it should be:
path = "/Repos/test123/MyRepo"
or
path = "${databricks_directory.test_directory.path}/MyRepo"
Not very experienced with Terraform. I upgraded my project from 12 to 13 and looking to upgrade it to 14 afterwards.
As the documentation specifies, I ran terraform 0.13upgrade and terraform 0.13upgrade module, my directory became like this:
terraform
├── module
│ ├── main.tf
│ └── versions.tf
├── main.tf
└── versions.tf
I moved my versions but the problem is that I specified them only in the root versions.tf:
terraform {
required_providers {
google = {
source = "hashicorp/google"
version = "~> 3.8.0"
}
}
in module/versions.tf I kept only:
terraform {
required_providers {
google = {
source = "hashicorp/google"
}
}
Do child modules inherit the version from the root (where they are imported) or does this mean my module will automatically run with a more recent provider version (3.64 I think)?
Should I simply remove module/versions.tf? (It's tiresome to have 2 versions to edit everytime).
Thanks!
For a given Terraform configuration (which includes both the root module and any other modules you might call), there can be only one version of each provider. Terraform recognizes that two providers are "the same" by them having the same source value after normalization, and in your examples here both are using hashicorp/google, which is short for registry.terraform.io/hashicorp/google, and so both of them need to be able to agree on a particular version of that provider to use.
Terraform handles version constraints from multiple providers by combining them together and trying to honor all of them together. In your examples here you've written no version argument in the child module, and this means "any version is allowed".
Terraform will therefore look for an available provider version that matches both the ~> 3.8.0 constraint and the implied "any version" constraint, and since the ~> 3.8.0 constraint is a proper subset of "any version" it effectively takes priority over the open constraint in the child module. This is not strictly "inheritance", but it happens to behave somewhat like it in this case because the child module is totally unconstrained.
A more interesting example would be if both of your modules specified different version constraints, which means we can see a more interesting effect of combining them. Let's pretend that your two modules had the following requirements instead:
terraform {
required_providers {
google = {
source = "hashicorp/google"
version = "~> 3.8.2"
}
}
}
terraform {
required_providers {
google = {
source = "hashicorp/google"
version = ">= 3.8.5"
}
}
}
In this situation neither of these constraints is a subset of the other, but they do have some overlap: all of the 3.8.x versions from 3.8.5 onwards are acceptable to both modules. Therefore Terraform will select the newest available version from that set.
If you write two modules that have conflicting version constraints then that would be an error:
terraform {
required_providers {
google = {
source = "hashicorp/google"
version = "~> 3.7.0"
}
}
}
terraform {
required_providers {
google = {
source = "hashicorp/google"
version = "~> 3.8.5"
}
}
}
There is no provider version that is both a 3.7.x release and a 3.8.x release at the same time, so no release can ever possibly match both of these constraints, and thus provider version selection will fail. It's for this reason that the Terraform documentation section Best Practices for Provider Versions advises to use ~> version constraints only in the root module.
I searched for [rust] "instead of a package manifest" on this site before asking and found no hits. I also read about virtual manifests here but did not resolve my question.
My goal is to make changes to azul.
To achieve this I read about patching dependencies here, and now I have this Cargo.toml
[package]
name = "my_first_azul_app"
version = "0.1.0"
authors = ["Name <Email>"]
edition = "2018"
# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html
[dependencies]
azul = { git = "https://github.com/maps4print/azul" }
[patch."https://github.com/maps4print/azul"]
azul = { path = "../azul" }
In path ../azul I have checked out the azul project with git clone. In main.rs I have followed this to get,
extern crate azul;
fn main() {
println!("Hello world!");
}
Then I try to test
$ cargo run
error: failed to resolve patches for `https://github.com/maps4print/azul`
Caused by:
failed to load source for a dependency on `azul`
Caused by:
Unable to update /home/name/projects/azul
Caused by:
found a virtual manifest at `/home/name/projects/azul/Cargo.toml` instead of a package manifest
I do not understand the final caused by line.
If I remove the [patch] configuration, it "works".
Quoting because it fails to compile, but that is why I am trying to check it out and attempt a fix. What charges do I need to make to develop the azul dependency?
TIA,
looks like azul is using workspaces so if you want to refer to it via path you must point to the exact member(s) of that workspace.
azul's Cargo.toml contains
[workspace]
members = [
"cargo/azul",
"cargo/azul-css",
"cargo/azul-core",
"cargo/azul-layout",
"cargo/azul-text-layout",
"cargo/azul-widgets",
"cargo/azul-css-parser",
"cargo/azul-native-style",
]
so I believe you should be able to do something like:
[dependencies]
azul = { path = "../azul/cargo/azul"
azul-css = { path = "../azul/cargo/azul-css" }
you may need all/some of the members there.
I am attempting to deploy a Lambda function using Terraform, where my source files are in a different directory adjacent to where I have my Terraform files. I want to have Terraform do the zipping of the source files for me and deploy them into the Lambda. Terraform doesn't seem to want to recognize that my files are there, though.
My directory structure:
project_root/
deployment/
terraform/
my-terraform.tf
function_source/
function.py
I want it to package everything in function_source directory (there is only one file there now, but may be more later) and drop it into the deployment directory.
My Terraform:
data "archive_file" "lambda_zip" {
type = "zip"
output_path = "../function.zip"
source_dir = "../../function_source/"
}
resource "aws_lambda_function" "my_lambda" {
filename = "${data.archive_file.lambda_zip.output_path}"
function_name = "my-function"
role = "${aws_iam_role.lambda_role.arn}"
handler = "function.handler"
runtime = "python3.7"
}
When I run this, though, I get the error message data.archive_file.lambda_zip: data.archive_file.lambda_zip: error archiving directory: could not archive missing directory: ../../function_source/
I have tried using absolute paths without success (which wouldn't be a good solution anyway). I have also tried creating the .zip file manually and hardcoding its directly in Lambda declaration, but it only works if I put the .zip file in my terraform directory. It seems Terraform can only see files in its own directory or below, but I'd rather not co-mingle my source files there. Is there a way to do this?
I am using Terraform v0.12.4