-
Notifications
You must be signed in to change notification settings - Fork 242
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Terraform init with Azure DevOps and https for module source #223
Comments
I am hitting the same issue. Anyone with ideas? |
Same issue. |
Get the same issue, just found a workaround with the system access token.
resources:
repositories:
- repository: terraform-modules
type: git
name: terraform-modules
steps:
- bash: git config --global http.https://<your_org>@dev.azure.com.extraheader "AUTHORIZATION: bearer $(System.AccessToken)" And then you should be able to run |
thanks @b1n9s I will take a look at that workaround. It looks usefull if there is only one (or a few) repository(s), but we have for each module a single repository, so as of now 27 module repos. |
@b1n9s so, I have tested the workarround I isn't working as we have more then 20 module repos and azure is limiting that to max 20. |
@srjennings @VOVELEE @b1n9s First part of our solution:
that is what also @b1n9s has mentioned. Second part of our solution: With both parts together, everything seams to work now. |
Can confirm, @Joerg-L 's solution works! |
Wow, I was hitting my had to the wall with this one, I am running a terragrunt with azure repos as git, using it inside the container job, and I tried a lot of things inlcuding using the ssh key as git_ssh_command, tried to install using the installsshkey, with this I switched the sources to use https rather than ssh, and with this little trick it finally worked. |
Thanks for that! |
Hey @Isaac-Irvine
The problem is that the System.AccessToken is bounded to the project specific build account. I have just checkt it in Azure DevOps, you can grant permissions in "ProjectB" to the Build Account of "ProjectA". |
In case anyone is still having issues, I found that using http..extraheader to work best for inserting and cleaning up afterwards as it keeps the token part of the value, as opposed to the URI. - pwsh: git config --global --add http.${{variables['System.CollectionUri']}}.extraheader "AUTHORIZATION: bearer $(System.AccessToken)" cleanup task: - pwsh: git config --global --unset-all http.${{variables['System.CollectionUri']}}.extraheader |
Hello, All can someone please help me with the sourcing of specific modules... Currently, I find the below solution which works for me locally but I would like to know if there is a better approach someone follows. module "my-module" {
source = "git::https://dev.azure.com/<org>/<project>/_git/<repo>//<module-folder>?ref=<branch||tag>"
variable = ...
variable = ...
} ++ @Joerg-L |
@tyagivasu But then you would need to use a relative path for sourcing in the module, not sure if it's a better approach for you. |
Hi @b1n9s thanks for your reply. Actually, that is what exactly I have today :) But I am looking to move in the HTTP:// source direction to roll out specific module versions, And would like to hear from people on any challenges, and approaches are taken while going to the https:// kind of sourcing. |
Thanks @Joerg-L |
I'm facing a similar issue for a github repo. Have not had success following these solutions. Has anyone else faced this? |
Yes @bmv0161. I recently ported from ADO to GitHub too. Similar issues |
For me @b1n9s , it was caller repo in ADO and module repo in ADO. Then migrated my ADO pipeline to GitHub Actions. Caller repo in GitHub and module repo in GitHub. Both had similar issues. Not sure this is a TF issue. Perhaps better discussed on Stackoverflow |
@gregdskb For sure this is not a TF issue. Not sure how your auth is configured in the GitHub Actions, but one thing to note, the
|
For me, both the caller repo and the module repo are in Github. With deployment in Azure pipelines. Attempting to use the System.AccessToken with a Github Apps Service Connection does not seem to authenticate properly. |
Here's another solution which is using environment variables instead. You won't have to use "global variables" so there's no risk of issues with multiple builds in parallel (and leaking tokens to other builds). Azure pipeline: steps:
- script: |
export GIT_CONFIG_PARAMETERS="'url.https://$SYSTEM_ACCESSTOKEN@dev.azure.com.insteadof=https://<YOUR_ORG>@dev.azure.com'"
terraform init
env:
SYSTEM_ACCESSTOKEN: $(System.AccessToken)
displayName: Initialize Terraform modules The module is included via this snippet: module "mymodule" {
source = "git::https://<YOUR_ORG>@dev.azure.com/<YOUR_ORG>/<YOUR_PROJECT>/_git/<YOUR_REPO>//<PATH_IN_REPO>"
} |
Hey everyone. I am facing the same issue right now. We are trying to use a dedicated Azure Project for terraform modules. Within that, every module gets a single repo.
unfortunately none of the approaches working. Where are getting the following error message in the azure pipeline:
|
hitting the same issue and as mentioned by @karts499 I tried all options suggested in comments here and still getting the same problem : |
So I'm not a fan of disabling this project wide setting Protect access to repositories in YAML pipelines. I don't think that is a good idea. Read more about job access tokens here. There is a reason it is enabled by default. With a test configuration repo and a test terraform modules repo hosted in the same Project I managed to get it working.
First adding the additional repository as a resource and explicitly in a checkout step. resources:
repositories:
- repository: terraform_modules
type: git
name: terraform_modules
steps:
- checkout: self
- checkout: terraform_modules When the pipeline runs you will be prompted to authenticate to the extra repository (hint, job access token now has permission to read from that repo 🤘) Secondly, add the git config. I chose to use an environment variable which will only last per the variable scope (the job in the case of my test pipeline). If you choose to use/set git global config (especially on a self hosted agent) there may be danger ahead if the agent is shared etc. - script: |
export GIT_CONFIG_PARAMETERS="'url.https://$SYSTEM_ACCESSTOKEN@dev.azure.com.insteadof=https://<YOUR_ORG_NAME_GOES_HERE>@dev.azure.com'"
terraform --version -json
terraform init
terraform plan
env:
SYSTEM_ACCESSTOKEN: $(System.AccessToken)
displayName: Test Init and Plan
workingDirectory: $(Build.SourcesDirectory)/config_test_repo/test1 Really that is it. Example of a module source: module "name" {
source = "git::https://<ORGNAME>@dev.azure.com/<ORGNAME>/<PROJECT_NAME>/_git/terraform_modules//modules/<MODULE_NAME>?ref=v2"
...
} Success. Can use References:https://learn.microsoft.com/en-us/azure/devops/pipelines/security/secure-access-to-repos?view=azure-devops&tabs=yaml |
Hey everyone. After long nights of debugging and try and errors. We finally found a workaround.
I should basicly do the same like my try with pwsh. Dont understand what exactly made the difference. Let me know if you have a better solution :) |
I was able to get it working with these steps + 1 additional step where I had to map the additional repositories that each job consumes. jobs:
- job:
uses:
repositories:
- terraform-modules |
I found a work around: 1: Create a service connection for inter-repo access( option called "Azure Repos/Team Foundation Server"_). You'll need to create a PAT.
repositories:
module "" { P.S |
So, we are using Azure Devops to store our Terraform config and all the self created module code.
We also want to use a DevOps Pipeline to apply the configuration.
As we are not allowed to use ssh for accessing the repos (traffic has to go trough the https-proxy), so we have to use https for the repository integration so that our source for the module looks like
Locally running
terraform init
works completely fine. When running it in the pipeline we see followingWe have tested many things right now and only with changeing source to
we were able to run
terraform init
but checking in PAT to git sounds not very right.Anyone an idea on that?
Regards
Joerg
The text was updated successfully, but these errors were encountered: