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

Regression: matrix builds with vmImage broke recently. #134

Closed
carllerche opened this Issue Mar 1, 2019 · 13 comments

Comments

Projects
None yet
8 participants
@carllerche
Copy link

carllerche commented Mar 1, 2019

Doing the following results in all matrix jobs using the ubuntu vm:

jobs:
- job: foo
  displayName: foo
  strategy:
    matrix:
      Linux:
        vmImage: ubuntu-16.04
      MacOS:
        vmImage: macOS-10.13
      Windows:
        vmImage: vs2017-win2016
  pool:
    vmImage: $(vmImage)

This regression happened recently within the past (couple of days)?

Example project: https://github.com/tokio-rs/tokio

Discussion: https://www.reddit.com/r/rust/comments/aw4b1g/azure_pipelines_for_rust_projects/ehjs7so/?st=jsqeps9x&sh=6cefea12

@johnterickson

This comment has been minimized.

Copy link

johnterickson commented Mar 1, 2019

[Edit] Nevermind, I see it here:
image

@carllerche - I am seeing this, too, in my fork, but it appears to be a UI bug. Can you confirm the build is actually running on the wrong VM?

For example,
https://dev.azure.com/johnterickson/rrinlog/_build/results?buildId=411&_a=summary

"Cross musl" shows up as "Hosted VS2017" in the UI:
image

but it actually running on Ubuntu:
image

@carllerche

This comment has been minimized.

Copy link
Author

carllerche commented Mar 1, 2019

One symptom that I am seeing is that it is not running the windows step for installing rust: https://dev.azure.com/tokio-rs/Tokio/_build/results?buildId=57

@mikeharder

This comment has been minimized.

Copy link

mikeharder commented Mar 1, 2019

We are seeing the same regression. Here's an example build:

https://dev.azure.com/azure-sdk/public/_build/results?buildId=6361

You can verify all builds were run on Windows via the build logs.

@carllerche

This comment has been minimized.

Copy link
Author

carllerche commented Mar 1, 2019

Yes, it appears to be running the windows build on a linux agent. You can check the "Query rust and cargo versions".

From the "windows" build:

rustc 1.33.0 (2aa4c46cf 2019-02-28)
binary: rustc
commit-hash: 2aa4c46cfdd726e97360c2734835aa3515e8c858
commit-date: 2019-02-28
host: x86_64-unknown-linux-gnu
release: 1.33.0
LLVM version: 8.0
cargo 1.33.0 (f099fe94b 2019-02-12)
@mikeharder

This comment has been minimized.

Copy link

mikeharder commented Mar 1, 2019

In our DevOps org, this regressed on Wed 2/27 between 11:25AM and 11:50AM Pacific Time:

Correct OS (11:25 AM): https://dev.azure.com/azure-sdk/public/_build/results?buildId=6147
Incorrect OS (11:50 AM): https://dev.azure.com/azure-sdk/public/_build/results?buildId=6155

@patrickcarnahan

This comment has been minimized.

Copy link

patrickcarnahan commented Mar 1, 2019

@mikeharder we are looking into this right now. We will follow up once we have determined the root cause.

@patrickcarnahan

This comment has been minimized.

Copy link

patrickcarnahan commented Mar 1, 2019

@mikeharder we have found the commit that broke it and are tracking down the developer to determine the proper course of action.

@TingluoHuang

This comment has been minimized.

Copy link
Member

TingluoHuang commented Mar 1, 2019

@mikeharder we are in the process of releasing the fix to the service.

@nickbabcock

This comment has been minimized.

Copy link

nickbabcock commented Mar 2, 2019

This appears fixed this morning. Except there is a UI bug. The UI still says ubuntu, but the actual agent is windows:

image

@TingluoHuang

This comment has been minimized.

Copy link
Member

TingluoHuang commented Mar 2, 2019

@nickbabcock thanks for let us know, i will report this to our UI team.
@yaananth do you know who owns that part?

@mikeharder

This comment has been minimized.

Copy link

mikeharder commented Mar 2, 2019

Confirmed fixed for our DevOps org as well

@yaananth

This comment has been minimized.

Copy link
Member

yaananth commented Mar 4, 2019

We have internal bug #1403537 tracking for wrong pool name issue

@jerickmsft

This comment has been minimized.

Copy link
Member

jerickmsft commented Mar 6, 2019

@yaananth @TingluoHuang I'm thinking we should close out this issue as the LSI is resolved.

@yaananth yaananth closed this Mar 7, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.