[JIRA] [acceptance-test-harness] (JENKINS-30009) Generates Dockerfile programmatically from DockerContainer

5 views
Skip to first unread message

asotobueno@cloudbees.com (JIRA)

unread,
Aug 18, 2015, 9:52:01 AM8/18/15
to jenkinsc...@googlegroups.com
Alex Soto created an issue
 
Jenkins / Improvement JENKINS-30009
Generates Dockerfile programmatically from DockerContainer
Issue Type: Improvement Improvement
Assignee: Alex Soto
Components: acceptance-test-harness
Created: 18/Aug/15 1:51 PM
Labels: test-harness docker
Priority: Minor Minor
Reporter: Alex Soto

Generates Dockerfile programmatically from DockerContainer instead of relying to docker fixture directory.
In this way a DockerContainer is able to generate its own Dockerfile structure without depending on other directory. Moreover it will make DockerContainer more compact since all information and everything that it is required for building the container will be at same place.

Add Comment Add Comment
 
This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265)
Atlassian logo

asotobueno@cloudbees.com (JIRA)

unread,
Aug 27, 2015, 6:09:01 AM8/27/15
to jenkinsc...@googlegroups.com
Alex Soto commented on Improvement JENKINS-30009
 
Re: Generates Dockerfile programmatically from DockerContainer

An example of how a class would look like:

import org.jboss.shrinkwrap.api.GenericArchive;
import org.jboss.shrinkwrap.api.ShrinkWrap;
import org.jboss.shrinkwrap.api.asset.StringAsset;
import org.jboss.shrinkwrap.descriptor.api.Descriptors;
import org.jboss.shrinkwrap.descriptor.api.docker.DockerDescriptor;

public class DockerIdea {


    @WithFixture
    public static GenericArchive createFixture() {
        DockerDescriptor descriptor = Descriptors.create(DockerDescriptor.class)
                        .from("ubuntu")
                        .run("apt-get update", "apt-get install -y openssh-server", "mkdir -p /var/run/sshd")
                        .run("useradd test -d /home/test", "mkdir -p /home/test/.ssh")
                        .entrypoint("/usr/sbin/sshd", "-D", "-e");

        return ShrinkWrap.create(GenericArchive.class, "sshd")
                .add(new StringAsset(descriptor.exportAsString()), "dockerfile");
    }

   @Test
    public void ....

}

Notice that now the fixture class is compact as it contains all the information it requires in a single source.

asotobueno@cloudbees.com (JIRA)

unread,
Aug 27, 2015, 6:30:01 AM8/27/15
to jenkinsc...@googlegroups.com
Alex Soto edited a comment on Improvement JENKINS-30009
An example of how a class would look like:

{code:java}

import org.jboss.shrinkwrap.api.GenericArchive;
import org.jboss.shrinkwrap.api.ShrinkWrap;
import org.jboss.shrinkwrap.api.asset.StringAsset;
import org.jboss.shrinkwrap.descriptor.api.Descriptors;
import org.jboss.shrinkwrap.descriptor.api.docker.DockerDescriptor;

public class DockerIdea {


    @WithFixture
    public static GenericArchive createFixture() {
        DockerDescriptor descriptor = Descriptors.create(DockerDescriptor.class)
                        .from("ubuntu")
                        .run("apt-get update", "apt-get install -y openssh-server", "mkdir -p /var/run/sshd")
                        .run("useradd test -d /home/test", "mkdir -p /home/test/.ssh")
                        .entrypoint("/usr/sbin/sshd", "-D", "-e");

        return ShrinkWrap.create(GenericArchive.class, "sshd")
                .add(new StringAsset(descriptor.exportAsString()), "dockerfile");
    }

   @Test
    public void ....

}
{code}


Notice that now the fixture class is compact as it contains all the information it requires in a single source.

jglick@cloudbees.com (JIRA)

unread,
Aug 27, 2015, 8:47:01 AM8/27/15
to jenkinsc...@googlegroups.com

What is the point of this? Everyone knows (or should learn) Dockerfile syntax. The existing system works fine IMO.

asotobueno@cloudbees.com (JIRA)

unread,
Aug 28, 2015, 9:59:01 AM8/28/15
to jenkinsc...@googlegroups.com

Well there is one use case which would be better. If you see on SSHD example in https://github.com/jenkinsci/acceptance-test-harness/blob/master/src/main/resources/org/jenkinsci/test/acceptance/docker/fixtures/SshdContainer/Dockerfile the keys are hardcoded directly, but in the test https://github.com/jenkinsci/acceptance-test-harness/blob/master/src/main/java/org/jenkinsci/test/acceptance/docker/fixtures/SshdContainer.java are get directly from the test folder where the keys where generated. Of course you can do what is done here of copying paste the keys, but this is in my opinion not the best way since you may have failures of test because of any change of keys, but not changing them in Dockerfile.

jglick@cloudbees.com (JIRA)

unread,
Aug 28, 2015, 10:28:02 AM8/28/15
to jenkinsc...@googlegroups.com

It is the fixture, not the test, which defines the private keys.

In this case it is probably a simple mistake that the Dockerfile redundandly hardcodes the public keys, rather than loading them from the resources directory where they are already defined:

COPY unsafe.pub unsafe_enc_key.pub /tmp/
RUN cat /tmp/*.pub > /home/test/.ssh/authorized_keys

With that fixed, there is not much real chance of mistakes when working on the fixture, since the public and private keys are all plainly grouped in one source directory.

jglick@cloudbees.com (JIRA)

unread,
Aug 28, 2015, 10:34:01 AM8/28/15
to jenkinsc...@googlegroups.com

Also an advantage of the existing system is that you can work on the Dockerfile (and/or its associated resource files) without even running acceptance tests, just by using docker build -t testing src/main/resources/org/jenkinsci/test/acceptance/docker/fixtures/Whatever && docker run -ti testing /bin/bash. Since the tests can take several minutes apiece to run, this is a much more pleasant way to play with minor modifications to the container before you check your work in the actual test. I recall doing that for XvncSlaveContainer: before trying to run Jenkins and its XVNC plugin against the server, I first needed to do a lot of experimentation to get permissions and the like right, and these could be simulated just by running the container, logging in as the Jenkins user, and checking if xmessage or the like ran without errors.

asotobueno@cloudbees.com (JIRA)

unread,
Aug 28, 2015, 10:37:01 AM8/28/15
to jenkinsc...@googlegroups.com

In any case I wanted to remove the other way, simply I wanted to add more features.

ogondza@gmail.com (JIRA)

unread,
Aug 15, 2019, 9:10:03 AM8/15/19
to jenkinsc...@googlegroups.com
Oliver Gondža closed an issue as Won't Do
 

I am closing this with as something we will not implement.

Change By: Oliver Gondža
Status: Open Closed
Resolution: Won't Do
This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)

jglick@cloudbees.com (JIRA)

unread,
Aug 15, 2019, 12:23:01 PM8/15/19
to jenkinsc...@googlegroups.com
Jesse Glick commented on Improvement JENKINS-30009
 
Re: Generates Dockerfile programmatically from DockerContainer

Which reminds me, we should consider deprecating docker-fixtures altogether and moving everything over to testcontainers.org.

Reply all
Reply to author
Forward
0 new messages