AEM Cloud Config Pipeline Failed due to YAML parsing error | Community
Skip to main content
Mahedi_Sabuj
Community Advisor
Community Advisor
September 26, 2024
Solved

AEM Cloud Config Pipeline Failed due to YAML parsing error

  • September 26, 2024
  • 2 replies
  • 1690 views

We tried to whitelist domains only for specific IP addresses. Given the large number of domains and IP addresses, we aimed to make the configuration more readable and manageable by separating the lists into different files using the YAML lookup method as shown below: 

- name: domains-ip-restriction when: allOf: - reqProperty: domain in: "{{ lookup('file', 'restricted_domains.yaml') }}" - reqProperty: clientIp notIn: "{{ lookup('file', 'whitelisted_ips.yaml') }}" action: type: block

restricted_domains.yaml:

- dev.domain1.com - dev.domain2.com

whitelisted_ips.yaml:

- 172.143.23.10/32

However, the config pipeline failed with the following error logs: 

2024-09-24T18:22:28+0000 Summary of events during the deployment step: 2024-09-24T18:22:28+0000 Begin deployment in sites-dev [CorrelationId: XXX] 2024-09-24T18:23:15+0000 Config Pipeline update status is failed 2024-09-24T18:23:15+0000 Error details are present: 2024-09-24T18:23:15+0000 Could not parse yaml file in 'restricted_domains.yaml'. Please check that you are using valid YAML syntax and check the documentation 2024-09-24T18:23:15+0000 Finished deployment in aaaem-sites-dev

We are aware that IP Allowlist can be configured via Cloud Manager for restricted websites. However, in our case, some domains need to be publicly accessible, which is why we are using this approach with CDN configuration.

Any suggestions on how to proceed with separate files for the IPs and domain lists, or is the only approach to duplicate these lists directly in the cdn.yaml file?

 

 

This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.
Best answer by Mahedi_Sabuj

I have already raised a ticket with the Adobe Support team and awaiting their response. Thanks.


From Adobe Support Team

I just heard back from the team and they mentioned that we do not support this kind of syntax unfortunately, therefore only 1 file can be used. Also they mentioned that this is not a YAML feature per say but an extension of YAML that some softwares, like Ansible, provide. So, I think the solution here would be to use Inline config.

 

2 replies

somen-sarkar
Community Advisor
Community Advisor
September 27, 2024

Hi @mahedi_sabuj ,

Have you tried to inline lists directly in yaml file  and check if the build is happening fine  ? This is to rule out any lookup file issue. 

 

- name: domains-ip-restriction when: allOf: - reqProperty: domain in: ["dev.domain1.com", "dev.domain2.com"] - reqProperty: clientIp notIn: ["172.143.23.10/32"] action: type: block

Thanks,

Somen

Mahedi_Sabuj
Community Advisor
Community Advisor
September 27, 2024

Inline config works fine, but we prefer managing IP addresses in a separate file for better reusability across different rules. This approach allows us to use the same IP addresses in multiple rules without duplication.

Mahedi Sabuj
somen-sarkar
Community Advisor
Community Advisor
September 28, 2024

In this case the issue can be in the format of the lookup  file  that you are trying to attach  or  pipeline script might have some specific conditions that it checks.  As per current documentation every yaml file has a common syntax like  below . 

kind: "LogForwarding" version: "1" metadata: envTypes: ["dev"]

As you are passing yaml file what changes were done to pass the list as an array to the required property field ? In publicly available documentation don't see any option to append a lookup file or valid "kind" type for lookup.  Suggest  to raise an Adobe support ticket  to get further inputs from the engineering team.

Thanks,

Somen

kautuk_sahni
Community Manager
Community Manager
October 9, 2024

@mahedi_sabuj Did you find the suggestion helpful? Please let us know if you require more information. Otherwise, please mark the answer as correct for posterity. If you've discovered a solution yourself, we would appreciate it if you could share it with the community. Thank you!

Kautuk Sahni