Skip to content
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

Be able to select agent queue with matrix, similar way as container #4

Closed
VasiliyNovikov opened this issue Oct 5, 2018 · 10 comments
Closed
Labels
enhancement New feature or request

Comments

@VasiliyNovikov
Copy link

Provide a way to select agent queues with matrix the same way as containers described here:
Container jobs - Multiple jobs

Use case - I have .NET Core library that needs to be built and tested on all platforms - Windows, Linux & Mac. Right now I can solve it with Job reuse with parameters but I think matrix would be more "natural" and less verbose way to do that

Moved from here: #1815

@ericsciple
Copy link
Contributor

We're working on adding this scenario soon. Next one or two sprints. Our sprints are 3-weeks long, and then take another 3 weeks to roll out to all accounts.

@ericsciple
Copy link
Contributor

@vtbassmatt fyi, a request for multi-job

@MSP-Greg
Copy link

@VasiliyNovikov

Agreed. Just tried to do the same thing myself. A 'matrix variable' seems to be visible or usable everywhere but when used with vmImage...

@vtbassmatt
Copy link
Member

@MSP-Greg we're fixing that now. We're moving strategy expansion earlier in the process so that it can be used with vmImage.

@mikeharder
Copy link

@MSP-Greg we're fixing that now. We're moving strategy expansion earlier in the process so that it can be used with vmImage.

@vtbassmatt: Do you know when this new behavior should be live? Is there an open issue tracking this work (this issue was closed 17 days ago)?

@vtbassmatt
Copy link
Member

It slipped into this sprint, and we have 2 more weeks to go. Then it will start rolling out across the service.

@mikeharder
Copy link

@vtbassmatt: Would it make sense to re-open the issue until the fix is deployed?

@vtbassmatt
Copy link
Member

We use these issues to discuss and track work remaining on our team. Deployments are provided for us, so there's not a lot of value in keeping a bug around waiting for that. Arguably we closed this one too early since we hadn't yet committed the code, which is leading to the extremely long delay between "issue closed" and "fix observable in practice". We'll try to be more diligent about that.

@mikeharder
Copy link

@vtbassmatt: Should this be live now?

@vtbassmatt
Copy link
Member

It's rolling out this week and into next.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

5 participants