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

(maint) Add docker specifics to git testing #81

Merged

Conversation

melissa
Copy link
Contributor

@melissa melissa commented Nov 16, 2018

Unfortunately there isn't a ticket for this work.

However, there are two things that are happening as a part of this
commit.

First, we don't want to try to download or unpack the runtime tarball.
If we're using docker to run the tests, the user should be pulling an
image that already has all the stuff that runtime provides. Hopefully
they're using a relatively new image that corresponds to whatever branch
they're working on. This is a big assumption, but it allows us to remove
the requirement that this be run on infrastructure that is only internal
to puppet.

Next, we allow dependencies to be installed from a directory that has
been bind mounted into the docker container. This will let us run tests
against a code base that we can be modifying as we go. We don't have to
figure out how to sync any changes up to the server that tests are
running on. They're just there! There are also some pretty big
assumptions with this, but again, it's worth the risk IMO.

I detailed some of this in comments in the code, but I'll add it here
too.

The hosts file should look something like this:

---
HOSTS:
  hostname-1:
    hypervisor: docker
    image: agent-runtime-master:latest
    docker_image_commands:
      -
      -
      -
    mount_folders:
      puppet:
        host_path: ~/puppet
        container_path: /build/puppet

This means that the hosts file that beaker-hostgenerator currently
creates for you is insufficient. You can still generate one using
beaker-hostgenerator, but you will likely want to go in and update it.

bundle exec beaker-hostgenerator -tdocker debian8-64m-debian8-64a > hosts.yaml

@melissa melissa force-pushed the maint/master/beaker-docker-docker-docker branch from 75f1d2c to 9d4ae85 Compare November 16, 2018 00:29
Unfortunately there isn't a ticket for this work.

However, there are two things that are happening as a part of this
commit.

First, we don't want to try to download or unpack the runtime tarball.
If we're using docker to run the tests, the user should be pulling an
image that already has all the stuff that runtime provides. Hopefully
they're using a relatively new image that corresponds to whatever branch
they're working on. This is a big assumption, but it allows us to remove
the requirement that this be run on infrastructure that is only internal
to puppet.

Next, we allow dependencies to be installed from a directory that has
been bind mounted into the docker container. This will let us run tests
against a code base that we can be modifying as we go. We don't have to
figure out how to sync any changes up to the server that tests are
running on. They're just there! There are also some pretty big
assumptions with this, but again, it's worth the risk IMO.

I detailed some of this in comments in the code, but I'll add it here
too.

The hosts file should look something like this:

```
---
HOSTS:
  hostname-1:
    hypervisor: docker
    image: agent-runtime-master:latest
    docker_image_commands:
      -
      -
      -
    mount_folders:
      puppet:
        host_path: ~/puppet
        container_path: /build/puppet
```

This means that the hosts file that beaker-hostgenerator currently
creates for you is insufficient. You can still generate one using
beaker-hostgenerator, but you will likely want to go in and update it.

`bundle exec beaker-hostgenerator -tdocker debian8-64m-debian8-64a > hosts.yaml`
@melissa melissa force-pushed the maint/master/beaker-docker-docker-docker branch from 9d4ae85 to b79db2a Compare November 16, 2018 00:30
Copy link
Contributor

@caseywilliams caseywilliams left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Jenkins failures look unrelated -- 👍!

@melissa
Copy link
Contributor Author

melissa commented Nov 16, 2018

Jenkins retest this please

@melissa
Copy link
Contributor Author

melissa commented Nov 16, 2018

jenkins test failure is because I force pushed to my branch. Sometimes it takes a little while for it to handle that update

@melissa
Copy link
Contributor Author

melissa commented Nov 16, 2018

Jenkins retest this please

@mchllweeks mchllweeks merged commit 15d76bc into puppetlabs:master Nov 19, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants