Feature #15181: Azure pipelines vc builds? help needed - Ruby master - Ruby Issue Tracking System

Actions

Copy link

Feature #15181

closed

Azure pipelines vc builds? help needed

Added by MSP-Greg (Greg L) over 5 years ago. Updated about 5 years ago.

Status:

Closed

Assignee:

Target version:

[ruby-core:89222]

Description

Wasn't long ago that all the Appveyor CI did was a vc120 job. Now, with three jobs, it can get quite backed up. Also, Appveyor seems to be inconsistent, as the test times can vary quite a bit, along with intermittent failure issues.

With the recent introduction of Azure pipelines, I thought I'd take a look, as they offer Ubuntu 16.04, MacOS, and a few Windows images. They also allow parallel builds (up to 10?) like Travis. Hence, the Windows CI time could be cut down to approx one third of what it is now.

Notes:

The image that contains both vc120 & vc140 is the vs2015-win2012r2 image. It does not contain any of the items needed for the vc builds. No bison, sed, openssl, or 7z to help with installing them.
Appveyor is using 'OpenSSL-Win64' (? on vers). It's currently built with vc140. For the Azure testing, I built two OpenSSL 1.1.1 packages, one built with vc120, one with vc140. I also created a special 7zip package, as the Windows Explorer shell integration makes it difficult to install the standard exe or msi packages in Azure.
The current pipelines web pages are very graphical, many things don't appear to have hard links available.

Both the VC builds fail around generating parse.c, the link for the build is at:
https://dev.azure.com/MSP-Greg/ruby/_build/results?buildId=83&view=logs

For the above link, (graphical UI), one needs to click in the area of the red 'x' with 'Build' to the right of it. That should open the log for that 'step'.

Since the current build system requires bison & sed, rather than download & install the whole MSYS2 system, I just downloaded the packages needed for bison & sed. Both respond to --help and --version, and the path is set correctly.

But, the nmake commmand stops as shown below:

compiling ../pack.c
pack.c
generating parse.c
NMAKE : fatal error U1077: 'D:\msys64\usr\bin\bison.EXE' : return code '0xd00'
Stop.

Microsoft (R) Program Maintenance Utility Version 12.00.21005.1
Copyright (C) Microsoft Corporation.  All rights reserved.

compiling ../version.c
version.c
generating parse.c
NMAKE : fatal error U1077: 'D:\msys64\usr\bin\bison.EXE' : return code '0xd00'
Stop.
The system cannot find the path specified.

I don't know what's causing this failure. Any suggestions would be appreciated.

Thanks, Greg

Actions

Copy link

#1 [ruby-core:89252]

Updated by MSP-Greg (Greg L) over 5 years ago

@naruse (Yui NARUSE)

I've got vc12, vc14, and mingw all building and passing btest and test-basic.

Given that the current Appveyor build takes approx 90 minutes, and an Azure pipelines build could cut that down to approx 35 to 40 minutes, I thought it worth looking into. Some notes:

At present, there are three files, one file in the root, azure-pipelines.yml, and two ps1 (Windows PowerShell script) files in tool. One script is azure_pipeline_prereqs_vc.ps1, which downloads and installs the additional software needed for the two vc builds, and another, azure_pipeline_prereqs_mingw.ps1, which does the same for the mingw build. They also set up the build/job variables. These two ps1 files could also be placed in win32.
Installing a full MSYS2/MinGW build system only takes approx 2:30 for the MinGW build. The VC builds do require some MSYS2 files for bison & sed, but that's a much smaller install.
The vc system uses three files I have hosted at BinTray. The first is a 7Zip zip file that allows install without all the shell integration. The other two are OpenSSL 1.1.1 packages, one build with vc120, the other with vc140. They were built on Appveyor.
Both vc and mingw are having issues with test-all & test-spec. The vc builds won't start either. MinGW has 19946 tests, 5062336 assertions, 6 failures, 2 errors, 245 skips for test-all results, and test-spec seems to have no failures, but freezes around 78%.
The Pipeline env is set up with two drives, the repo is on D, and the main image is on C. The temp files directory is on C, and also has a path where the username is more than eight characters. The seems connected to some of the mingw test-all failures/errors. I do recall having the same issues a long time ago when I was working on a desktop with a similar setup, but at the time, there were more important issues with test reliability, etc.
As stated above, I believe Travis is using Ubuntu 14.04. Pipelines has an image with Ubuntu 16.04. That could also be added to the build matrix.