Closed dwl285 closed 4 years ago
Scheduling works for the standard dev.azure.com
token, but fails for the custom hosted domain (the evidence here being from the customer, as we don't have our own custom set up). Further steps:
Investigate whether the dataform:${this.gitProps.gitToken}@${objectUrl.hostname}
url format isn't actually allowed for the custom domain, and what the correct form should be.
Change scheduler access tokens to actually try and read from the repo to determine their validity, rather than using the API. This would prevent future occurrences of expecting a schedule to run, then not having it run (which is a terrible UX).
Some further digging revealed that the repository we're having the issue with is just using the old format for azure repos, which looks like some_subdomain.visualstudio.com
, as described in the thread here: https://developercommunity.visualstudio.com/content/problem/765309/switch-existing-organizations-to-use-the-new-domai.html. Recommendation for that customer is to upgrade their project away from the deprecated url format.
The second point is still valid though, of validating scheduler access tokens directly against the repo
Closed as issue solved and awaiting DD
Notes from discussion: Making that show invalid for custom domains is difficult, as there's no generic API for us to test against.
Currently we use a well defined API for each, e.g. the GitHub API, Gitlab etc, but if there's an odd domain like this then we can't test the token is correct without running it against a git repo. Running against a git repo for a user token doesn't make any sense though, as the token can (potentially) authenticate many repos!
A workaround for this specific case would be to check the url for the .visualstudo. regex, then use the Azure API (with ...visualstudio. as the host).