Unexpected configuration file read/search behavior in update_script.rb

[rgrace-puck]

Is your feature request related to a problem? Please describe.

The extension code seems to have a proper fallback for cloning scenarios, but the ruby script does not.
This results in a partially correct reading of the dependabot.yml (e.g. for private credentials), but the rest of the configuration is ignored.

extension/task/utils/parseConfigFile.ts searches "Build.SourcesDirectory" for the configuration file:

dependabot-azure-devops/extension/task/utils/parseConfigFile.ts

Lines 81 to 93 in f0d575a

	} else {
	let rootDir = getVariable("Build.SourcesDirectory");
	for (const fp of possibleFilePaths) {
	var filePath = path.join(rootDir, fp);
	if (fs.existsSync(filePath)) {
	tl.debug(`Found configuration file cloned at ${filePath}`);
	contents = fs.readFileSync(filePath, "utf-8");
	break;
	} else {
	tl.debug(`No configuration file cloned at ${filePath}`);
	}
	}
	}

...but updater/bin/update_script.rb does not, it uses Dependabot::Config::FileFetcher:

dependabot-azure-devops/updater/bin/update_script.rb

Lines 490 to 500 in f0d575a

	cfg_file = Dependabot::Config::FileFetcher.new(
	source: cfg_source,
	credentials: $options[:credentials],
	options: $options[:updater_options]
	).config_file
	puts "Using configuration file at '#{cfg_file.path}' 😎"
	Dependabot::Config::File.parse(cfg_file.content)
	rescue Dependabot::RepoNotFound, Dependabot::DependencyFileNotFound
	puts "Configuration file was not found, a default config will be used. 😔"
	Dependabot::Config::File.new(updates: [])
	end

which results in the following network calls (as seen in logs):

2023-10-16T13:20:13.4994042Z Looking for configuration file in the repository ...
2023-10-16T13:20:13.4998391Z 🌍 --> GET https://dev.azure.com/org/project/_apis/git/repositories/repo
2023-10-16T13:20:13.6681872Z 🌍 <-- 200 https://dev.azure.com/org/project/_apis/git/repositories/repo
2023-10-16T13:20:13.6688561Z 🌍 --> GET https://dev.azure.com/org/project/_apis/git/repositories/repo/stats/branches?name=main
2023-10-16T13:20:13.8010466Z 🌍 <-- 200 https://dev.azure.com/org/project/_apis/git/repositories/repo/stats/branches?name=main
2023-10-16T13:20:13.8017843Z 🌍 --> GET https://dev.azure.com/org/project/_apis/git/repositories/repo/items?path=.github/dependabot.yml&versionDescriptor.versionType=commit&versionDescriptor.version=141b6889d915169b7f97d43114755f3ca95f1848
2023-10-16T13:20:13.9300757Z 🌍 <-- 404 https://dev.azure.com/org/project/_apis/git/repositories/repo/items?path=.github/dependabot.yml&versionDescriptor.versionType=commit&versionDescriptor.version=141b6889d915169b7f97d43114755f3ca95f1848
2023-10-16T13:20:13.9304075Z 🌍 --> GET https://dev.azure.com/org/project/_apis/git/repositories/repo/items?path=.github/dependabot.yaml&versionDescriptor.versionType=commit&versionDescriptor.version=141b6889d915169b7f97d43114755f3ca95f1848
2023-10-16T13:20:14.0559530Z 🌍 <-- 404 https://dev.azure.com/org/project/_apis/git/repositories/repo/items?path=.github/dependabot.yaml&versionDescriptor.versionType=commit&versionDescriptor.version=141b6889d915169b7f97d43114755f3ca95f1848
2023-10-16T13:20:14.0562053Z Configuration file was not found, a default config will be used. 😔

Describe the solution you'd like

I'd like the ruby script to also have the ability to support cloning scenarios so that configuration files can be read locally, and not from a network call reading the most current version of the repository itself.

Describe alternatives you've considered
N/A

Additional context
N/A

[rgrace-puck]

Thinking about this more, it seems unexpected that more network calls are made to fetch repository contents after everything has already been cloned.

As a user, I'd expect this to follow "normal" pipeline behavior and just use what has been provided from previous tasks.
It also creates a "race" as pipelines can run in stages (may require approval) and aren't always run immediately after one another.

[mburumaxwell]

With #884 and #885, we no longer parse the configuration file in the Ruby script. Instead, all details are read in the extension (on task execution) or server (during sync) then the information is passed to the Ruby script in docker via ENV variables. This was meant to reduce the work done but has since worked against us.