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

VSTS CI Schema Change #17978

Merged
merged 8 commits into from Sep 6, 2018

Conversation

Projects
None yet
2 participants
@chrisrpatterson
Contributor

chrisrpatterson commented Sep 4, 2018

Requirements

  • Filling out the template is required. Any pull request that does not include enough information to be reviewed in a timely manner may be closed at the maintainers' discretion.
  • All new code requires tests to ensure against regressions

Description of the Change

Updating the VSTS CI configuration to match the latest schema.

Alternate Designs

N/A

Why Should This Be In Core?

N/A

Benefits

As users see the config or try to make changes the config here should match the doc

Possible Drawbacks

Possible I missed something and break the CI

Verification Process

Created a build pipeline on my own account based on the update YAML and all three jobs passed successfully

Applicable Issues

n/a

chrisrpatterson added some commits Aug 31, 2018

Fix strategy and timeout
Changing the matrix to match new strategy schema.  and moving timoutInMinutes up.
Added explicit python version
Updated  Windows job to specify python version
Rolling back to vs2015 image
For some reason the vs2017 image can't build with python 2.7 and gyp properly.
@daviwil

This comment has been minimized.

Show comment
Hide comment
@daviwil

daviwil Sep 4, 2018

Member

Thanks a lot, Chris! I'll keep an eye on the build and merge when it goes green.

Member

daviwil commented Sep 4, 2018

Thanks a lot, Chris! I'll keep an eye on the build and merge when it goes green.

@daviwil

This comment has been minimized.

Show comment
Hide comment
@daviwil

daviwil Sep 5, 2018

Member

Looks like our macOS agent pool keeps timing out, causing the builds to fail. Any idea why that's happening?

https://github.visualstudio.com/Atom/_build/results?buildId=6206&view=logs

Member

daviwil commented Sep 5, 2018

Looks like our macOS agent pool keeps timing out, causing the builds to fail. Any idea why that's happening?

https://github.visualstudio.com/Atom/_build/results?buildId=6206&view=logs

@chrisrpatterson

This comment has been minimized.

Show comment
Hide comment
@chrisrpatterson

chrisrpatterson Sep 5, 2018

Contributor

@daviwil there was a pretty major outage in a data center today and that is possibly the issue. There should be a new option on the build in the drop down to re-run that build without needed to push an update to the PR now.

Contributor

chrisrpatterson commented Sep 5, 2018

@daviwil there was a pretty major outage in a data center today and that is possibly the issue. There should be a new option on the build in the drop down to re-run that build without needed to push an update to the PR now.

@daviwil

This comment has been minimized.

Show comment
Hide comment
@daviwil

daviwil Sep 5, 2018

Member

Seems to be running smoothly now!

Member

daviwil commented Sep 5, 2018

Seems to be running smoothly now!

@daviwil

This comment has been minimized.

Show comment
Hide comment
@daviwil

daviwil Sep 5, 2018

Member

After running "Rebuild" on the previous build, the new build failed because it couldn't upload artifacts:

2018-09-05T02:25:15.5585100Z Uploading 1 files
2018-09-05T02:25:20.6729460Z Total file: 1 ---- Processed file: 0 (0%)
2018-09-05T02:25:31.1542370Z Total file: 1 ---- Processed file: 0 (0%)
2018-09-05T02:25:40.6846800Z Total file: 1 ---- Processed file: 0 (0%)
2018-09-05T02:25:43.5478420Z Fail to upload '/Users/vsts/agent/2.139.1/work/1/a/atom-mac.zip' due to 'TF400813: The user '37997752-33c2-4c03-970c-cdc086fbc5e2' is not authorized to access this resource.'.
2018-09-05T02:25:43.5505160Z Microsoft.VisualStudio.Services.Common.VssUnauthorizedException: TF400813: The user '37997752-33c2-4c03-970c-cdc086fbc5e2' is not authorized to access this resource.
   at Microsoft.VisualStudio.Services.Common.VssHttpMessageHandler.<SendAsync>d__17.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Microsoft.VisualStudio.Services.Common.VssHttpRetryMessageHandler.<SendAsync>d__4.MoveNext()

Also, any chance we could swap position of "Queue" with "Rebuild" on PR builds? That's the likely action someone will want to take on a failed build and I don't think folks will realize they should look in the "..." menu.

Member

daviwil commented Sep 5, 2018

After running "Rebuild" on the previous build, the new build failed because it couldn't upload artifacts:

2018-09-05T02:25:15.5585100Z Uploading 1 files
2018-09-05T02:25:20.6729460Z Total file: 1 ---- Processed file: 0 (0%)
2018-09-05T02:25:31.1542370Z Total file: 1 ---- Processed file: 0 (0%)
2018-09-05T02:25:40.6846800Z Total file: 1 ---- Processed file: 0 (0%)
2018-09-05T02:25:43.5478420Z Fail to upload '/Users/vsts/agent/2.139.1/work/1/a/atom-mac.zip' due to 'TF400813: The user '37997752-33c2-4c03-970c-cdc086fbc5e2' is not authorized to access this resource.'.
2018-09-05T02:25:43.5505160Z Microsoft.VisualStudio.Services.Common.VssUnauthorizedException: TF400813: The user '37997752-33c2-4c03-970c-cdc086fbc5e2' is not authorized to access this resource.
   at Microsoft.VisualStudio.Services.Common.VssHttpMessageHandler.<SendAsync>d__17.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Microsoft.VisualStudio.Services.Common.VssHttpRetryMessageHandler.<SendAsync>d__4.MoveNext()

Also, any chance we could swap position of "Queue" with "Rebuild" on PR builds? That's the likely action someone will want to take on a failed build and I don't think folks will realize they should look in the "..." menu.

@chrisrpatterson

This comment has been minimized.

Show comment
Hide comment
@chrisrpatterson

chrisrpatterson Sep 6, 2018

Contributor

@daviwil that is expected when builds come from PRs from forks. At the moment we don't let those upload artifacts. It is something we are working to add but for now we block for security reasons. It is possible to conditionalize those out when the build is a PR from a fork.

Contributor

chrisrpatterson commented Sep 6, 2018

@daviwil that is expected when builds come from PRs from forks. At the moment we don't let those upload artifacts. It is something we are working to add but for now we block for security reasons. It is possible to conditionalize those out when the build is a PR from a fork.

@daviwil

This comment has been minimized.

Show comment
Hide comment
@daviwil

daviwil Sep 6, 2018

Member

Thanks! Trying this condition to see if it keeps artifact uploads from occurring on PR builds:

condition: and(succeeded(), ne(variables['Build.Reason'], 'PullRequest'))
Member

daviwil commented Sep 6, 2018

Thanks! Trying this condition to see if it keeps artifact uploads from occurring on PR builds:

condition: and(succeeded(), ne(variables['Build.Reason'], 'PullRequest'))
@daviwil

daviwil approved these changes Sep 6, 2018

All green now, thanks Chris!

@daviwil daviwil merged commit a988288 into atom:master Sep 6, 2018

3 checks passed

Atom Pull Requests #20180906.5 succeeded
Details
continuous-integration/appveyor/pr AppVeyor build succeeded
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment