I experienced this issue myself when trying to set up a local script as a GP service - I foolishly thought that the validation would "just know" that the hard-coded feature services were feature services and not local data and therefore would not attempt to copy the data when publishing. I attempted to publish the script with the hard-coded URLs and I ended up having to kill the publishing job as we all know it attempted to copy the data to the server despite no actual local data being referenced in the script.
The issue with validation flagging feature service URLs as file directories can be avoided by storing all URLs in a YAML configuration file. Instead of embedding/hard-coding the URLs directly in the script or tool, reference them dynamically by reading from the YAML file at runtime. This way, the only file that gets copied with the GP service is the small YAML file, avoiding any validation errors related to directory structures and drastically reducing the time to publish the GP service.
For example, you can structure the YAML file like this:
portal:
master_fs: https://yourserver.com/FeatureServer/0
feature_services:
other_fs1: "https://yourserver.com/FeatureServer/1"
other_fs2: "https://yourserver.com/FeatureServer/2"
other_fs3: "https://yourserver.com/FeatureServer/3"
Then, in your script, load the URLs dynamically:
import yaml
def read_config(config_path):
with open(config_path, 'r') as file:
return yaml.safe_load(file)
config = read_config("config.yaml")
master_feature_service = config["portal"]["master_fs"]
feature_service_urls = config["feature_services"]
This approach ensures that no hardcoded paths cause validation issues and makes it easier to update URLs without modifying the script itself. You can modify the YAML file published with the GP service by going to the file directory for the GP service on your server if you need to add/remove variables.
Hope this helps anyone that has been struggling with this issue!
