I'm sorry that the product wasn't easier to use, and that it wasted so much of your time. For anyone else running into this, we do have docs up about how to access authenticated submodules: https://docs.microsoft.com/en-us/azure/devops/pipelines/repo... (that shows how to do it against another Azure Repos instance, but a variation will work for any Git provider with a PAT-style bearer token)

It is likely that this is a variant of the issue with secure files. Secure files require a song and dance around changing the default branch or committing directly to a default branch to trigger a build after setup of the secure file. Coming from CI systems like Travis and Circle, this is an extremely confusing approach that I hope they consider changing.

Yes, we rolled out some improvements to how we authorize secure files (and other resources such as variable groups, agent pools, service connections) that you use in a YAML file. First, we introduced a toggle on each of these resources to mark them as "authorized in all pipelines". For new resources that you create, this will be on by default. Second, when you queue a build in the new YAML editor under Pipelines hub, then you get the option to correct the resource authorization issue. More work needs to be done here so that we can give you the right experience while maintaining the security of protected resources, and all of that is planned over the next month or two. Thanks.

That sounds like a great improvement to the process!