[ethomson]

I'm not in Redmond, but do send an email. I'm my HN name @microsoft.com. We should be able to sort out some of these issues for you. I'd like to hear more about the docs problem. But:

You should be able to recurse submodules in a pipeline. In the visual designer, select "Checkout Submodules" in the pipeline's get sources step. If you use YAML, set "submodules: true" or "submodules: recursive" in the checkout keyword.

You should also be able to specify environment variables (including PATH) with the env keyword. But do reach out and we can get to the bottom of this.

[plasma]

Hey, just one bit of feedback, I tried getting my github linked project to build late last year, but always failed to checkout sub modules.

The build log showed permission issues, and I did try workarounds suggested like changing the sub module URL and adding ssh keys as part of the checkout step, but in the end, my 8 hours allocated to “get vsts building” ended with this problem and I have not continued. The performance of builds was also poor.

It’s unfortunately burnt me enough that I’m just making an ec2 instance with teamcity.

[vtbassmatt]

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)

[toxicbakery]

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.

[vijayma]

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.

[toxicbakery]

That sounds like a great improvement to the process!