Hostname to container routing/Container persistence about gitness HOT 12 CLOSED

Hey Alex,

thanks for taking the time to provide feedback!

RE: Hostname/Port to container routing

I really want Drone to work with Selenium Grid and / or Sauce Labs. I'm definitely open to suggestions for getting this all working. Sauce Labs uses a proxy server as an alternative to exposing ports. Would something like this be possible for Selenium Grid? I've written proxy servers in Go before, I'd be happy to help get something like this working for Selenium Grid

RE: Container persistence

We have a CLI that allows you to test your build inside Docker containers, on your local computer / laptop. It is guaranteed to execute the same way locally that it executes on the Drone servers. We built this specifically for troubleshooting and debugging failures. Would this meet your requirement?
https://github.com/drone/drone/tree/master/cmd/drone

from gitness.

So the process that led me to the two feature suggestions is that I work at a University and often get feature requests or bug reports from people around the institution who aren't developers. Our current process is to push changes to a testing branch which gets deployed to a test infrastructure. On the whole this works but it doesn't really allow for big experimentation which might break that branch completely and can lead to divergence if code isn't then pushed to master.

Ideally I'd like to be able to create a pull request which is built and then pass a URL to the end user, often with little to no technical ability, for testing. The easier the is process the better.

from gitness.

Would a deployment not be suitable for that? Or do you want hands-on testing before a pull request is merged?

from gitness.

Testing prior to merge would be best as then iteration is just a case of pushing new commits to the same pull request. Deploying would just be an extra step and technically the code is already deployed in the test container.

from gitness.

I completely understand where you're coming from. I think the solution is to make deployment really easy from Drone, including deploying feature branches. I think this is definitely possible if we put some time into it.

Drone has the ability to notify individuals when a build completes. What if Drone could build and deploy your feature branch, and then notify your testers with the link?

I like the creative ideas. Let's keep brainstorming

from gitness.

I'm not keen on the word 'deployment' in this instance as it means that there has to be somewhere for the code to be deployed. That means extra infrastructure, virtual machines or something. To me that seems like uneccessary overhead when the code is already deployed in the container.

I'm glad that the idea is getting some discussion though and look forward to seeing what happens.

from gitness.

Is it possible to deploy to the same machine then in your case? I think
Brad's point is that deployment is more well suited (in the context of
Drone) to your situation rather than squeezing behavior where it may or may
not belong.

Also, wouldn't it be possible to add running the server at the end of your
build yml file? Just thinking off the top of my head, but you could build
to a container that exposes the ports you want and if a problem happens
during the build it'll fail as expected. As a last step start your server
and let it run.

Not sure how you'd stop it gracefully though...
On Feb 11, 2014 4:07 PM, "Alex Whitman" [email protected] wrote:

I'm not keen on the word 'deployment' in this instance as it means that
there has to be somewhere for the code to be deployed. That means extra
infrastructure, virtual machines or something. To me that seems like
uneccessary overhead when the code is already deployed in the container.

I'm glad that the idea is getting some discussion though and look forward
to seeing what happens.

Reply to this email directly or view it on GitHubhttps://github.com//issues/47#issuecomment-34813978
.

from gitness.

keeping the containers running redefines what a "build" means, in a way which breaks CI conventions. (ex: does the build pass when the tests finish, or when the container is stopped? do all permutations of a matrix build keep running, or only some?) when you consider the flow of adding commits to an existing pull request, attempting to inject those changes into a running container breaks the reproducibility guarantees which docker provides.

i agree with others in this thread that the idea of running successful builds in a way that can be manually tested has a direct mapping to the concept of deployment. automatically shipping the container which has a pre-merge copy of master + the PR to a docker host (even localhost) for validation is a cool idea, but is still deployment.

from gitness.

@scottferg Deploying to the same machine would be an option as that machine would already be set up to run containers. Having a server running would be necessary in some way for Selenium tests so how that is done is just a detail, probably with supervisor or something similar.

@afex I agree that injecting changes into a running container wouldn't be correct and that is what I meant by keeping the container running "until the build is superseded" by new commits. That would and should trigger a new build in a new container.

After the above comments and thinking about it a bit more, maybe this could be solved with two processes. Drone would do the building as it should but then once built just detach itself from the container rather than stopping it. Drone could then notify another process, via web hook, which can handle the domain/port routing as well as stopping the container when it's no longer required.

from gitness.

Should there not be an option to leave the container running? Rebuilding the container each time to run the tests can add up in time quickly. A typical Rails project has to install the entire rails stack gems and all each time to run the tests, the run the tests... In my experience with CI, teams don't like to wait much for the build process, esp if it is holding up going to the pub..

from gitness.

@surzycki see issue #43

A better option might be to snapshot a Docker image after things like libraries and gems are installed. Leaving the container running is not an option, since Docker runs a single process (the build script) and must exit with a status code, indicating success / failure.

from gitness.

Was any progress made on enabling Hostname/Port to container routing?

I have drone setup on a local mac inside vagrant, I also have a number of other virtual machines setup to run karma tests. However I need the build container to expose a port. I've built a build container with this port exposed but can't find any way of passing the -p flag to docker.

Any thoughts of how I can achieve this?

from gitness.