Travis, EL7 and Docker-Based Testing
Tags: travis, docker, git, rpm
Published: 2019-03-27 16:01:19

---
title: Travis, EL7 and Docker-Based Testing
published: true
tags: Travis,Docker,git,rpm
canonical_url: https://thjones2.blogspot.com/2019/03/travis-el7-and-docker-based-testing.html
---

As noted in a [prior post](https://www.blogger.com/blogger.g?blogID=3054063691986932274), a lot of my customer-oriented activities support deployment within networks that are either partially- or wholly-isolated from the public Internet. Yesterday, as part of supporting one such customer, I stood up a [new project](https://github.com/plus3it/priv-repo-rpm-builder) to help automate the creation of yum repository configuration RPMs for private networks. I've had to hand-jam such files twice, now, and there's unwanted deltas between the two jam-sessions (in my defense, they were separated from each other by nearly a three-year time-span ..and, each time, I'd figured the repositories' owners would be responsible enough to create and distribute their own configuration RPMs). So, I figured it was time to standardize and automate things.  
  
Usually, when I stand up a project, I like to include tests of the content that I wish to deliver. Since most of my projects are done in public GitHub repositories, I typically use [TravisCI](https://travis-ci.com/) to automate my testing. Prior to this project, however, I wasn't trying to automate the validity-testing of RPM recipes via Travis. Typically, when automating creation of RPMs I wish to retain or deliver, I set up a Jenkins job that takes the resultant RPMs and stores them in Artifactory – both privately-hosted services. Most of my prior Travis jobs were simple, syntax-checkers (using tools like [shellcheck](https://www.shellcheck.net/), JSON validators, [CFn validators](https://github.com/aws-cloudformation/cfn-python-lint), etc.) rather than functionality-checkers.  
  
This time, however, I was trying to deliver a functionality (RPM spec files that would be used to generate source files from templates and package the results). So, I needed to be able to test that a set of spec files and source-templates could be reliably-used to generate RPMs. This meant, I needed my TravisCI job to generate "throwaway" RPMs from the project-files.  
  
The TravisCI system's test-hosts are Ubuntu-based rather than RHEL or CentOS based.While there are some tools that will allow you to generate RPMs on Ubuntu, there've been some historical caveats on their reliability and/or representativeness. So, my preference was to be able to use a RHEL or CentOS-based context for my test-packagings. Fortunately, TravisCI _does_ offer the ability to use Docker on their test-hosts.  
  
In general, setting up a Docker-oriented job is relatively straight forward. Where things get "fun" is that the version of `rpmbuild` that comes with Enterprise Linux 7 gets kind of annoyed if it's not able to resolve the UIDs and GIDs of the files it's trying to build from (never mind that the build-user inside the running Docker-container is "root" ...and has unlimited access within that container). If it _can't_ resolve them, the rpmbuild tasks fail with a multitude of not terribly helpful "`error: Bad owner/group: /path/to/repository/file`" messages.  
  
After googling about, I ultimately found that I needed to ensure that the UIDs and GIDs of the project-content need to exist within the Docker-container's `/etc/passwd` and `/etc/group` files, respectively. Note: most of the "top" search results Google returned to me indicated that the project files needed to be `chown`ed. However, simply being _mappable_ proved to be sufficient.  
  
Rounding the home stretch...  
  
To resolve the problem, I needed to determine what UIDs and GIDs the project-content had inside my Docker-container. That meant pushing a Travis job that included a (temporary) diagnostic-block to stat the relevant files and return me their UIDs and GIDs. Once the UIDs and GIDs were determined, I needed to update my Travis job to add relevant groupadd and useradd statements to my container-preparation steps. What I ended up with was.

```
    sudo docker exec centos-${OS\_VERSION} groupadd -g 2000 rpmbuilder
    sudo docker exec centos-${OS\_VERSION} adduser -g 2000 -u 2000 rpmbuilder
```
  
It was late in the day, by this point, so I simply assumed that the IDs were stable. I ran about a dozen iterations of my test, and they stayed stable, but that may have just been "luck". If I run into future "`Bad owner/group`" errors, I'll update my Travis job-definition to scan the repository-contents for their current UIDs and GIDs and then set them based on _those_. But, for now, my test harness works: I'm able to know that updates to existing specs/templates or additional specs/templates will create working RPMs when they're taken to where they need to be used.