-
Notifications
You must be signed in to change notification settings - Fork 6
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
AzDevOpsProject: Integration tests fails intermittently with timeout error #25
Comments
The actions performed by the AzureDevOps API are asynchronous so the request (e.g POST or PUT) is made and you have to repeatedly request (GET) an updated operation to determine once AzureDevOps has completed it. The timeout I added (to prevent endless looping/waiting) may need it’s value increasing. AzureDevOps may be “busy” and taking a while to queue and perform the operations. I’ll try and take a look later today. |
I see! I think would be good if such timeout values can be set by the user in the configuration (but could have a default value). |
I agree it would be useful for the user to set and/or override, although it seems a little "painful" if we have to pass this into every resource - There are other options like this (e.g. the version of the API used) which is hardcoded at present, and I suspect there will be more. What about options for using environment variables in which to set/overide these without having to setup as resource properties? .. these would be more specific to overiding the way the resources were applied rather than the state of the resources? ... not sure what thoughts you have on this? Is this easily possible? Also, if you've now been able to merge the PR ( #20 ), I'll likely leave this issue for now and I'll try and take a look at a few of the issues (including this one) when I get a block of time (might be at the weekend or into next week). I'll try and get a few "quick wins" and tidy-ups into a PR, and then I might start looking at getting integration tests running in PRs - some of that will get most of the way towards another, initial resource (e.g. Finally, I'd still like to have a little look at setting up the resource to use one of the modules suggested by @kilasuit in the initial PR ( #7 ) to see what's involved and what could/might need to be changed (and it might remove requirement for some of the future changes). |
Added issue #27 to track the potential usage of the suggested dependent modules. |
I merged #20 so we can pick this up when we have time. Sometimes the tests must be manually kicked if they fail until this is resolved. 🙂
I see your point to have this in every resource. Since one normally wouldn't want one resource to have one timeout value and another a different timeout value it makes sense if it possible to get those values in another way. Then we need to have a new resource, or composite resource that is using |
…es (#28) - AzureDevOpsDsc - Increased Azure DevOps, API timeout to 5 minutes to allow for busy/slow API operations (issue #25). - Updated contextual help (issue #5). - Removed `Classes` directory from being output in packaged module (issue #10). - Removed `Examples` directory from being output in packaged module (issue #11). - Moved 'Ensure' and 'RequiredAction' enums into 'Enum' directory and out of 'prefix.ps1' (issue #12).
Details of the scenario you tried and the problem that is occurring
Integration tests is throwing a timeout error.
Verbose logs showing the problem
https://dev.azure.com/dsccommunity/AzureDevOpsDsc/_build/results?buildId=3735&view=logs&j=893fd6d3-ee14-5383-e15d-24a2acc7f145&t=417fa350-1299-5d83-5f55-4c06f3da5c2a&l=866
Suggested solution to the issue
The DSC configuration that is used to reproduce the issue (as detailed as possible)
From the integration tests, the configuration
AzDevOpsProject_EnsureProjectPresent_Config
Azure DevOps Server version the target node is running
Azure DevOps Services
VSTeam PowerShell modules present on the target node
Not applicable
The operating system the target node is running
Microosft Hosted Agent (Azure Pipelines) running the integration tests.
Version and build of PowerShell the target node is running
Not applicable
Version of the DSC module that was used
Latest
main
The text was updated successfully, but these errors were encountered: