Uploaded image for project: 'Data Management'
  1. Data Management
  2. DM-2053

Specify system for performing CI on Docker stack containers

    Details

    • Type: Epic
    • Status: Done
    • Resolution: Done
    • Fix Version/s: None
    • Component/s: QA
    • Labels:
      None
    • Epic Name:
      stack-CI-docker
    • Story Points:
      30
    • WBS:
      02C.01.02
    • Team:
      SQuaRE
    • Cycle:
      Winter 2016

      Description

      Investigate how we can CI first-party Docker containers with runnable stacks

      [JH 100%]

        Attachments

          Issue Links

          Stories in Epic (Custom Issue Matrix)

            Activity

            Hide
            jhoblitt Joshua Hoblitt added a comment -

            (Complete last weekend)

            It is possible for jenkins to spawn a container per job but the configuration is somewhat confusing. Essentially, the connection information and containers are defined globally and then the job is restricted to run on a slave with a label set in the global configuration. This is non-obvious as the label of slaves which aren't running (and no container slaves are running at this point) aren't represented as an option. However, if you type in the correct label it is accepted.

            The work flow is that jenkins spawns a new container via the docker/kubernetes API, sshes into it and starts the jenkins jnlp client. Once the container registers itself a slave with the master, the build is allowed to run on it and at completion, jenkins destroys the container.

            Testing was done with a regular docker engine bound to a ip socket instead of the default unix domain. A production configuration we need a swarm/kubernetes setup to schedule containers and investigation into how uses could create their own containers.

            Show
            jhoblitt Joshua Hoblitt added a comment - (Complete last weekend) It is possible for jenkins to spawn a container per job but the configuration is somewhat confusing. Essentially, the connection information and containers are defined globally and then the job is restricted to run on a slave with a label set in the global configuration. This is non-obvious as the label of slaves which aren't running (and no container slaves are running at this point) aren't represented as an option. However, if you type in the correct label it is accepted. The work flow is that jenkins spawns a new container via the docker/kubernetes API, sshes into it and starts the jenkins jnlp client. Once the container registers itself a slave with the master, the build is allowed to run on it and at completion, jenkins destroys the container. Testing was done with a regular docker engine bound to a ip socket instead of the default unix domain. A production configuration we need a swarm/kubernetes setup to schedule containers and investigation into how uses could create their own containers.
            Hide
            jhoblitt Joshua Hoblitt added a comment -

            Migrated DM-3627 to DM-3425 (EPIC) so that this EPIC can be closed out.

            Show
            jhoblitt Joshua Hoblitt added a comment - Migrated DM-3627 to DM-3425 (EPIC) so that this EPIC can be closed out.

              People

              • Assignee:
                jhoblitt Joshua Hoblitt
                Reporter:
                frossie Frossie Economou
                Watchers:
                Frossie Economou, Joshua Hoblitt
              • Votes:
                0 Vote for this issue
                Watchers:
                2 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:

                  Summary Panel