utils/update-checkout: Fix for --tag breakage in SR-3810

[colinhowell]

If invoked with --tag, and the specified tag does not exist in a repository,
update_repository_to_tag() will return with no value instead of an argument
list. update_all_repositories() must check for an absent value (meaning this
repository does not have the tag) before it appends the expected argument
list to the pool_args list of pooled arguments.

The fix is pretty simple: check whether the result returned by update_repository_to_tag() is an
actual list before appending it to the pooled list. (Before we were appending a None value, which
caused a Python library routine to break once the update commands were spawned.) If there's no list to append, nothing will be done for this repository, which is appropriate since it lacks this tag.

I tested this using the same test case described in #46395, and it appropriately did nothing
instead of triggering a Python traceback.

@erg, @gottesmm Could you give this a lookover? If it meets your approval, could one of you trigger appropriate CI test runs? I'm not sure what best fits an infrastructure script like this, and I don't think my account has the privileges to automatically trigger Swift CI runs anyway.

Resolves #46395.

[erg]

@swift-ci Please smoke test

[erg]

Alternate fix: #7190

Do we still want to do the actions that don't involve checking out the tag, or just do nothing?

[colinhowell]

I'm not sure myself. I based my fix on what I assumed was the intent of the code as originally written.

[erg]

I think we want to call update_single_repository no matter what. Otherwise, nothing at all will get done to repositories that don't have the tag, which is clearly against the spirit of an update script.

[erg]

@colinhowell Closing in favor of the patch that still does some work in case the tag does not exist. Thanks for the bug report and potential fix!

The --tag option does some work in serial before going parallel. If you had the time, maybe you could make this step go in parallel.

[colinhowell]

@erg, I'm looking into your suggestion about making the --tag option do its work in parallel. Actually, it looks like the --scheme option could be partly parallelized too, especially when it comes to the cross-repos stuff.

By the way, it looks to me like the --tag processing sets the cross_repo flag simply to prevent a rebase after the tag checkout. Is my understanding correct?

[erg]

@colinhowell Yes, I think the cross-repo line was hack to avoid dealing with the rebasing bugs and such. If the behavior is preserved, we can take out the hack.

It would be great to parallelize everything that makes sense!

[colinhowell]

@erg (Probably I should discuss this in a new PR, but since we're talking about it already...)

Actually I now have a modified version of update-parallel which parallelizes all per-repo activity that was in update_all_repositories(), update_repository_to_tag(), and update_repository_to_scheme(). This required refactoring the work in those functions, completely eliminating update_repository_to_tag() and update_repository_to_scheme(), with the (slightly simplified) results included in or called from update_single_repository() (whose size was kept down a bit by making two new helper functions corresponding to the old tag- and scheme-related functions).

Unfortunately it also means that I now have to pass eight arguments to update_single_repository(), rather than five, to give it all the info it needs. Though now I see that obtain_additional_swift_sources() gets passed nine arguments, so this isn't unprecedented.

[colinhowell]

@erg Oh, by the way, it also assumes that #7232 will eventually be accepted, which is why I haven't yet made a new PR.