Source-build: Enable RHEL7.5 public PR CI builds

Created on 2 Aug 2018  路  3Comments  路  Source: dotnet/source-build

Related: https://github.com/dotnet/source-build/issues/415 ("Re-enable RHEL CI (including offline)" for internal builds).

We can't use Red Hat Docker images for public CI due to ACR authentication secrets. This issue tracks getting RHEL7.5 PR builds set up some other way.

It's much less maintainable than Docker images, but we can set up a typical Helix queue for this.

  • [ ] Set up RHEL7.5 Helix queue

    • Install prereqs based on how it's done in Dockerfile commands.

  • [ ] Use queue in Jenkins to run PR builds.
area-ci-testing

Most helpful comment

Any serious issues would be caught in internal CI which can easily use RHEL Docker images.

I doubt the cost/benefit of using public CentOS/Fedora while maintaining private RHEL , ie dual maintenance, divergence across public/private. I'm more inclined to go CentOS/Fedora entirely.

All 3 comments

We can still do this, but there's a questionable value tradeoff vs. using CentOS and Fedora containers which should be suitable RHEL stand-ins. (Any serious issues would be caught in internal CI which can easily use RHEL Docker images.)

/cc @dleeapho

Any serious issues would be caught in internal CI which can easily use RHEL Docker images.

I doubt the cost/benefit of using public CentOS/Fedora while maintaining private RHEL , ie dual maintenance, divergence across public/private. I'm more inclined to go CentOS/Fedora entirely.

Yeah... as for benefit, I don't remember a bug for 2.1+ that happened in our RHEL builds that didn't happen in CentOS or Fedora.

There's a decent amount of infra pretty specific to this goal that could be cut:

  • dotnet-buildtools-prereqs-docker src/rhel/7.5/Dockerfile

    • A good reference and lets you easily build it yourself on your own Red Hat machine, but not so useful when we aren't actually using it to build anything and have no ongoing evidence that it works.

    • This Dockerfile also complicates the repo's infra: public CI can't validate it, and internally we needed to split the official build into two: one for the public images, one that runs on Red Hat and pushes to ACR for that one RHEL image.

    • /cc @MichaelSimons

  • source-build infra (in YAML and in the build definition itself) to support logging into a private registry to pull the build image.
  • VSTS pools of (static) Red Hat machines. (One in devdiv instance, a few in dnceng.)

    • Right now, source-build and the dotnet-buildtools-prereqs-docker repo are the only ones I know that intend to or do use these--most things use any old Linux with Docker and public images.

    • We should probably keep one of these around in case we can easily set up 1.0/1.1 servicing to build here. (Not sure it's as flexible across distros as 2.1+.)

    • /cc @crummel

  • (Not set up yet:) A way to run internal CI on merge and report it in a way we notice.

Agree, it seems better to simplify and only use public Docker images.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

PureTryOut picture PureTryOut  路  6Comments

omajid picture omajid  路  12Comments

crummel picture crummel  路  5Comments

omajid picture omajid  路  8Comments

tmds picture tmds  路  10Comments