Initial scripts and pipeline for stress test discovery/build/push #1851
Conversation
|
This pull request is protected by Check Enforcer. What is Check Enforcer?Check Enforcer helps ensure all pull requests are covered by at least one check-run (typically an Azure Pipeline). When all check-runs associated with this pull request pass then Check Enforcer itself will pass. Why am I getting this message?You are getting this message because Check Enforcer did not detect any check-runs being associated with this pull request within five minutes. This may indicate that your pull request is not covered by any pipelines and so Check Enforcer is correctly blocking the pull request being merged. What should I do now?If the check-enforcer check-run is not passing and all other check-runs associated with this PR are passing (excluding license-cla) then you could try telling Check Enforcer to evaluate your pull request again. You can do this by adding a comment to this pull request as follows: |
benbp
force-pushed
the
benbp/stress-ci-scripts
branch
from
6ddef3f
to
f3e7bb0
Compare
| - '!sdk/**/session-records' | ||
| - '!sdk/**/SessionRecords' | ||
|
|
||
| - task: AzureCLI@2 |
There was a problem hiding this comment.
What value are we gaining by using the AzureCLI task here? Is the service connection information enough for us to do all the deployments or don't we need to stull pass in most of the secrets? Also what about other clouds do they need other configurations or is that not a scenario at this point.
There was a problem hiding this comment.
I hadn't gotten to that point yet but my thinking was to add an access policy to the buildout bicep configs to allowlist one of the devops service connections (that way there are no manual steps on buildout). I may still create a new identity just for this.
I think it's unlikely that we'll target other clouds, as our aim here is to stress the client code, rather than to test its operability across clouds. Though if we do have a need for that, I don't think we'll ever need to host the stress cluster itself in another cloud, so any relevant credentials are not configured in this context (they are auto-synced into the cluster via keyvault).
|
@weshaggard The script pieces should be much more simplified now. I added a couple helpers for exit code + control flow handling, please let me know what you think. Also, I'm considering moving these scripts into |
| } | ||
|
|
||
| Write-Output "Creating namespace $($pkg.Namespace) if it does not exist..." | ||
| kubectl create namespace $pkg.Namespace --dry-run=client -o yaml | kubectl apply -f - |
There was a problem hiding this comment.
Should you use one of your run helpers here?
There was a problem hiding this comment.
I was having trouble dealing with > and | operators when passing them through to Run(), so there are a few places in the script where I bypass it to keep Run() simple. In all places the subsequent command will fail if the previous command fails and is not caught, however.
|
The following pipelines have been queued for testing: |
|
Hello @azure-sdk! Because this pull request has the p.s. you can customize the way I help with merging this pull request, such as holding this pull request until a specific person approves. Simply @mention me (
|
ghost
merged commit 
This adds some initial automation to:
The scripts are designed to be run either locally or via CI.
I have some testing to do on the pipeline config, but everything else is fully ready for review.
Resolves Azure/azure-sdk#3168