Getting error in pipeline, during build image

[ShaileshBassi]

Getting the error under build image in the pipeline execution.

Ran the local cloud validator and it does not show any error:

Error:

2022/07/04 15:04:24 /tmp/dispatcher/unzippedConfiguration: unable to find any farm in 'conf.dispatcher.d/enabled_farms'
The command '/bin/sh -c AZCOPY="/usr/bin/azcopy" VALIDATOR_BINARY="/usr/bin/dispatcher-configuration-validator" HTTPD_BINARY="/usr/sbin/httpd" DISPATCHER_CONFIGURATION_LOCATION=$dispatcherConfigurationLocation DISPATCHER_CONFIGURATION_DESTINATION=$dispatcherConfigurationDestination DISPATCHER_IMAGE=$dispatcherImage RUN_MODE=$runmode ./validateDispatcherConfiguration.sh' returned a non-zero code: 2
2022/07/04 15:04:24 Container failed during run: validate-dispatcher. No retries remaining.
failed to run step ID: validate-dispatcher: exit status 2

I have checked the farm file as well and there is the entry within it. PFB:

#
# This is the default publish farm definition for the dispatcher module. 
#
# DO NOT EDIT this file, your changes will have no impact on your deployment.
#
# Instead create a copy in the folder conf.dispatcher.d/available_farms and edit the copy.
# Finally, change to the directory conf.dispatcher.d/enabled_farms, remove the symbolic
# link for default_farm.any and create a symbolic link to your copy.
#

/publishfarm {
	# client headers which should be passed through to the render instances
	# (feature supported since dispatcher build 2.6.3.5222)
	/clientheaders {
		$include "../clientheaders/clientheaders.any"
	}
	# hostname globbing for farm selection (virtual domain addressing)
	/virtualhosts {
		$include "../virtualhosts/virtualhosts.any"
	}
	# the load will be balanced among these render instances
	/renders {
		$include "../renders/default_renders.any"
	}
	# only handle the requests in the following acl. default is 'none'
	# the glob pattern is matched against the first request line
	/filter {
		$include "../filters/filters.any"
	}
	# if the package is installed on publishers to generate a list of all content with a vanityurl attached
	# this section will auto-allow the items to bypass the normal dispatcher filters
	# Reference: https://docs.adobe.com/docs/en/dispatcher/disp-config.html#Enabling%20Access%20to%20Vanity%20URLs%20-%20/vanity_urls
	# /vanity_urls {
	#	/url    "/libs/granite/dispatcher/content/vanityUrls.html"
	#	/file   "/tmp/vanity_urls"
	#	/delay  300
	# }
	# allow propagation of replication posts (should seldomly be used)
	/propagateSyndPost "0"
	# the cache is used to store requests from the renders for faster delivery
	# for a second time.
	/cache {
		# The cacheroot must be equal to the document root of the webserver
		/docroot "${DOCROOT}"
		# sets the level upto which files named ".stat" will be created in the
		# document root of the webserver. when an activation request for some
		# handle is received, only files within the same subtree are affected
		# by the invalidation.
		/statfileslevel "2"
		# caches also authorized data
		/allowAuthorized "0"
		# Flag indicating whether the dispatcher should serve stale content if
		# no remote server is available.
		/serveStaleOnError "1"
		# the rules define, which pages should be cached. please note that
		# - only GET requests are cached
		# - only requests with an extension are cached
		# - only requests without query parameters ( ? ) are cached
		# - only unauthorized pages are cached unless allowUnauthorized is set to 1
		/rules {
			$include "../cache/rules.any"
		}
		# the invalidate section defines those pages which are 'invalidated' after
		# any activation. please note that, the activated page itself and all 
		# related documents are flushed on an modification. for example: if the 
		# page /foo/bar is activated, all /foo/bar.* files are removed from the
		# cache.
		/invalidate {
			/0000 {
				/glob "*"
				/type "deny"
			}
			/0001 {
				/glob "*.html"
				/type "allow"
			}
			# to ensure that AEM forms HTMLs are not auto-invalidated due to invalidation of any other resource. It is supposed to be deleted only after its own activation.
			/0002
			{
				/glob "/content/forms/**/*.html"
				/type "deny"
			}
		}
		/allowedClients {
			$include "../cache/default_invalidate.any"
		}
		# The ignoreUrlParams section contains query string parameter names that
		# should be ignored when determining whether some request's output can be
		# cached or delivered from cache.
		# In this example configuration, the "q" parameter will be ignored.
		# /ignoreUrlParams {
		#	/0001 { /glob "*" /type "deny" }
		#	/0002 { /glob "q" /type "allow" }
		# }

		# Cache response headers next to a cached file. On the first request to
		# an uncached resource, all headers matching one of the values found here
		# are stored in a separate file, next to the cache file. On subsequent
		# requests to the cached resource, the stored headers are added to the
		# response.
		# Note, that file globbing characters are not allowed here.
		/headers {
			"Cache-Control"
			"Content-Disposition"
			"Content-Type"
			"Expires"
			"Last-Modified"
			"X-Content-Type-Options"
		}
		# A grace period defines the number of seconds a stale, auto-invalidated
		# resource may still be served from the cache after the last activation
		# occurring. Auto-invalidated resources are invalidated by any activation,
		# when their path matches the /invalidate section above. This setting
		# can be used in a setup, where a batch of activations would otherwise
		# repeatedly invalidate the entire cache.
		/gracePeriod "2"

		# Enable TTL evaluates the response headers from the backend, and if they
		# contain a Cache-Control max-age or Expires date, an auxiliary, empty file
		# next to the cache file is created, with modification time equal to the
		# expiry date. When the cache file is requested past the modification time
		# it is automatically re-requested from the backend.
		/enableTTL "1"
	}
}

Any suggestions?

Thanks 

[tusharbias]

unable to find any farm in conf.dispatcher.d/enabled_farms

Your enabled farms should be located in the mentioned subfolder.

file included (…) must be named: …

There are two sections in your farm configuration that must include a
specific file: /renders and /allowedClients in the /cache section. Those
sections must look as follows:

/renders {
    $include "../renders/default_renders.any"
}

and:

/allowedClients {
    $include "../cache/default_invalidate.any"
}

Refer for more information it has complete information about this issue:

https://experienceleague.adobe.com/docs/experience-manager-cloud-service/content/implementing/conten... 

[ShaileshBassi]

@tusharbias I checked about the points mentioned in the thread above. Everything is already there as per the documentation.

Thanks 

[jalaja]

@ShaileshBassi Could you please try below steps to resolve the dispatcher error 'unable to find any farm in 'conf.dispatcher.d/enabled_farms':
1. On the project directory, go to folder /dispatcher/src/conf.dispatcher.d/available_farms/ and locate a file called default.farm.
2. Delete the content in default.farm at location /dispatchersrc/conf.dispatcher.d/enabled_farms/ and replace with '../available_farms/default.farm'.

Run the pipeline again.

[ShaileshBassi]

@jalaja I have already executed the below steps: 

1. Delete the file under "/dispatchersrc/conf.dispatcher.d/enabled_farms/"
2. Ran the command, which create the symlink for the file

mklink "<file-location>\dispatcher\src\conf.dispatcher.d\enabled_farms\default.farm" "<file-location>\dispatcher\src\conf.dispatcher.d\available_farms\default.farm"

And then ran the pipeline.

Right now, what I could sense from some of the links that it creates the problems which the symlinks are created from the windows machine. Is that true?

Thanks

[Gucci-Paull-108]

For knowledge share, a symbolic link only works in a *nix based file system. The link gets committed back to Source Control. To create this type of link on a MS Windows O/S, you need to use the Wins Subsystem for Linux add-on for Wins v10 [0]. Wins shortcuts/links do not function in the Dispatcher container, and are not supported in the GIT repository.

[0] https://docs.microsoft.com/en-us/windows/wsl/install-win10

[ShaileshBassi · Accepted solution]

Thanks for the response @Gucci-Paull-108. The symlink issue got fixed with teh Wins Subsytem.
But the build is still failing, but no error seen in the buildimage logs.

@jalaja @Gucci-Paull-108 Can you help here, what could have gone wrong. PFB for the buildimage log snippet

Successfully built 427b7d8f291c
Successfully tagged cmpl0va80ctrg0build0prd.azurecr.io/dispatcher-validation:ca24wfq
2022/07/06 11:38:32 Successfully executed container: validate-dispatcher
2022/07/06 11:38:32 Step ID: create-dockerfile marked as successful (elapsed time in seconds: 0.564543)
2022/07/06 11:38:32 Step ID: prefetch-images marked as successful (elapsed time in seconds: 3.623359)
2022/07/06 11:38:32 Populating digests for step ID: prefetch-images...
2022/07/06 11:38:33 Successfully populated digests for step ID: prefetch-images
2022/07/06 11:38:33 Step ID: validate-dispatcher marked as successful (elapsed time in seconds: 18.040090)
2022/07/06 11:38:33 Populating digests for step ID: validate-dispatcher...
2022/07/06 11:38:34 Successfully populated digests for step ID: validate-dispatcher
2022/07/06 11:38:34 The following dependencies were found:
2022/07/06 11:38:34 
- image:
    registry: cmpl0va80ctrg0build0prd.azurecr.io
    repository: preload
    tag: ca24wfq
  runtime-dependency:
    registry: cmpl0va80ctrg0build0prd.azurecr.io
    repository: aem-ethos/dispatcher-publish
    tag: 2.0.104
    digest: sha256:efcf9d49375278eeb3c7ef61b4a762b0fca796770d4905c2c622938fb3d9b80d
  git: {}
- image:
    registry: cmpl0va80ctrg0build0prd.azurecr.io
    repository: dispatcher-validation
    tag: ca24wfq
  runtime-dependency:
    registry: cmpl0va80ctrg0build0prd.azurecr.io
    repository: aem-ethos/dispatcher-publish
    tag: 2.0.104
    digest: sha256:efcf9d49375278eeb3c7ef61b4a762b0fca796770d4905c2c622938fb3d9b80d
  git: {}

Run ID: ca24wfq was successful after 28s

Thanks

[Gucci-Paull-108]

Log a support case with us because a few other customers have reported this today too. Don't forget to include this forum thread URL in description field.