Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Feb 20 05:53
    @ashwilliams1 banned @matrixbot
  • Oct 18 2019 03:30
    @bradrydzewski banned @vityafx
  • May 07 2019 20:55
    @bradrydzewski banned @izznogooood
Ben Magee
@BnMcG
The two container definitions that change are for the drone/git plugin container and the drone/docker plugin container
https://github.com/drone-runners/drone-runner-kube/blob/874bebd82e7e91534ff9fca3d7285917ba303b0a/engine/compiler/step.go Does Drone create the pod with placeholder containers initially then swap in the image later?
Brad Rydzewski
@bradrydzewski
yep
Ben Magee
@BnMcG
I'd assume those are the container restarts that are logged then
Brad Rydzewski
@bradrydzewski
similar to Tekton, all containers are created using a placeholder image that just sleeps. When it is time for the step to start, Drone replaces the image.
thus starting the step
Ben Magee
@BnMcG

OK, so I think what's happening in this case is I'm killing the pipeline because of some network issue that's causing a Docker pull to fail to pull the base image - but this seems to retry for some period of time:

2.2-alpine: Pulling from dotnet/core/sdk
89d9c30c1d48: Pulling fs layer
13fe2e501eab: Pulling fs layer
a8c94b32079c: Pulling fs layer
019289223955: Pulling fs layer
19ad50654db2: Pulling fs layer
019289223955: Waiting
19ad50654db2: Waiting
a8c94b32079c: Retrying in 5 seconds
a8c94b32079c: Retrying in 4 seconds
a8c94b32079c: Retrying in 3 seconds
a8c94b32079c: Retrying in 2 seconds
a8c94b32079c: Retrying in 1 second
13fe2e501eab: Retrying in 5 seconds
13fe2e501eab: Retrying in 4 seconds
13fe2e501eab: Retrying in 3 seconds
13fe2e501eab: Retrying in 2 seconds
13fe2e501eab: Retrying in 1 second
13fe2e501eab: Retrying in 10 seconds
13fe2e501eab: Retrying in 9 seconds
13fe2e501eab: Retrying in 8 seconds
13fe2e501eab: Retrying in 7 seconds
13fe2e501eab: Retrying in 6 seconds
13fe2e501eab: Retrying in 5 seconds
13fe2e501eab: Retrying in 4 seconds
13fe2e501eab: Retrying in 3 seconds
13fe2e501eab: Retrying in 2 seconds
13fe2e501eab: Retrying in 1 second
13fe2e501eab: Verifying Checksum
13fe2e501eab: Download complete

I'd guess I'm killing the pipeline and the pod is sitting there retrying for ages - I'm assuming at some point this either succeeds in the background or times out and gives up and the pod is cleaned up by Drone

Working on the info above that Drone only reaps the pod once all containers exit - perhaps there's some other behaviour I don't know about that should be kicking in here
Brad Rydzewski
@bradrydzewski
sorry, I'm not sure I can do much more to help
Ben Magee
@BnMcG
The actual build issue isn't a Drone problem, I'm just wondering if there's some logic already implemented to kill the pod in the scenario above (pipeline cancelled but container keeps running for a long time in the background)
Or if Drone always waits for all containers to exit before tidying up
Brad Rydzewski
@bradrydzewski
yes
if Drone receives a signal to terminate the pipeline, it immediately invokes the function to cleanup the pod

the destroy function is invoked here:

and drone uses the context.Context to listen for cancellation events here:

and this context is also passed to the code that listens for the container to exit. If the context is cancelled, Drone stops waiting for the container to exit:

Brad Rydzewski
@bradrydzewski
although I have tested cancelling pipelines, it is certainly possible there are edge cases that we haven't accounted for in our code that I simply did not encounter. But that is where we need people who can reliably reproduce the problem to triage and send a patch.
Ben Magee
@BnMcG

It's late here so I'm not going to try and dive into it now, but I think I am hitting an edge case somewhere. At a guess it's something along the lines of having at least 1 step complete in a pipeline, and then cancel on a long-running step

It seems like right now I can reliably reproduce the problem, I'm not sure I'm really familiar enough with the codebase or how Drone communicates with the kube-runner and Kubernetes to be able to submit a patch though

Brad Rydzewski
@bradrydzewski
no worries. We have a large community so if it ends up being a widespread issue, someone will certainly dive in and send a patch.
Brad Rydzewski
@bradrydzewski
but in case you want to trace through the code, here is where Drone listens for cancel events from the server (this code is the same for all runners):
https://github.com/drone-runners/drone-runner-kube/blob/master/runtime/runner.go#L114:L125
Ben Magee
@BnMcG
Cheers, will try and take a look when I get time
willgithub
@willzhang
does https://cloud.drone.io/ support pull and save docker images?
how can i config it ?
when i want use docker:dind , i have error as follow
default: linter: untrusted repositories cannot enable privileged mode
林博仁(Buo-ren Lin)
@Lin-Buo-Ren
Hello, I would like to ask whether there is documentation regarding setting up Nginx as a reverse proxy to the Drone site
It seems that there was once documented in 0.8.0 at https://0-8-0.docs.drone.io/setup-with-nginx but now it is no where to be found...?
Jesse Quinn
@jessequinn
i do this easily with docker-compose
jwilder/nginx-proxy and jrcs/letsencrypt-nginx-proxy-companion:latest
kolaente
@kolaente
Hey there, is there a way to restrict certain runners for certain users?
More specifically, we have a macos runner exec which we would like to restrict to prevent users other than a select group from executing builds on it
since it's going to be used in a foss project
Brad Rydzewski
@bradrydzewski
@kolaente an exec runner can be limited to specific repositories and events (e.g. push, pull request, etc)

but generally speaking, the exec runner is not suitable for this use case for security reasons

When to Avoid?
The Exec runner is not suitable for untrusted workloads due to lack of isolation. We recommend using the Docker runner for all projects by default, and only using the Exec runner for the subset of projects requiring host machine access.

kolaente
@kolaente
@bradrydzewski Thanks for that quick answer!
I'm all for using only docker runners, but ios builds only work on macos unfortunately
Brad Rydzewski
@bradrydzewski
@kolaente I hear you. The exec runner is unsafe by design so there is not much you could do. You could try to create an extension that augments Drone's behavior. For example, a conversion extension that disables an exec pipeline for an unknown user.
we are also working with MacStadium to try and come up with a dynamic osx runner, but that is probably at least 6 weeks out
very early discussions with them right now
also that would require MacStadium Enterprise Cloud. Depending on the size of your organization, the cost could be difficult to justify
Thomas Boerger
@tboerger
There is also an option to build an anka-build runner if you got some hosted Mac and want to buy an anka license.
Henrik Hørlück Berg
@henrikhorluck
Hello! I am having an issue trying to set up a multi-step python pipeline, but the installed packages (with pip/poetry) are not kept across steps (especially Black, isort, and flake8 are not in PATH), is there any way to fix that?
Brad Rydzewski
@bradrydzewski
@henrikhorluck create a data volume at the path where the dependencies are installed
this will ensure they are persisted and available to all pipeline steps
in terms of the PATH, you can set the path in your commands section at shown here.
Henrik Hørlück Berg
@henrikhorluck
Thank you very much, will test it out as soon as I can!
Ben Magee
@BnMcG
Should I be able to substitute variables defined in DRONE_RUNNER_ENV_FILE in my pipeline using the interpolation syntax ${bla}?
Ben Magee
@BnMcG
https://github.com/drone/drone/blob/fa8e17dc3764d58bdef575f8bb8c97a3a90c6add/operator/runner/runner.go#L199 It looks like the substitution may happen on the server side, so perhaps it's not possible to substitute variables defined in DRONE_RUNNER_ENV_FILE