I was wondering, has there been a consideration to move drone up the stack, and have it rely on Kubernetes features to function?

It could potentially ease the burden of a lot of things Drone currently has to manage on top of Docker, and with minikube, running drone locally could become as simple as minikube create && drone deploy.

I know this is an extreme oversimplification of things, and it would obviously mean giving up some freedom (dependent on a container scheduler, instead of only Docker), but there are obviously also a lot of upsides to this.

This a summary of discussions made in Gitter to keep track of progress. Leave this issue to verified information. Keep the discussion to Gitter

Error: Within the git plugin container following error is throwed while cloning a repo from gitlab. This error have begun to appear with drone integration with recent versions of GitLab.

$ git init
Initialized empty Git repository in /drone/src/git.company.se/company/placeholder-prototype/.git/
$ git remote add origin https://git.company.se/company/sleepy-prototype.git
$ git fetch --depth=50 origin +refs/heads/master:
fatal: could not read Username for 'https://git.company.se': No such device or address

Versions: The error have been reproduced using: gitlab-8.0.4-0, gitlab-8.0.4-1 Anton Ikonovalov cant reproduce this error on version gitlab-8.0.3-1. Something have probably happen in later version which breaks Drone from working.

Older versions of GitLab CE could be found here: https://packages.gitlab.com/gitlab/gitlab-ce

Next step:

• Try clone_mode=oauth in your drone gitlab configuration string
• Try to manually create netrc locally and test it with GitLab.

Hi! Thanks for open sourcing this, it's a great thing.

I'm opening this issue to discuss a potential decoupling from Docker. It's noticeable that Drone was built for cloud services, allowing clients to run under a specific container (e.g. just Ruby2.0).

What world needs is a good Jenkins replacement. It's something people would install with 1 click on any platform (I'm looking at you OSX), and be able to run the job on a host machine. Something people would update with just go get or git pull and go install.

It's a big set of users, as currently there's no sane self-hosted CI for building iOS apps.

this issue will discuss a strategy for an official arm image for drone.

• [x] ability to define platform in yaml
• [x] ability to route builds to agents by platform
• [x] publish linux/arm agent
• [x] publish linux/arm64 agent
• [x] publish linux/arm git plugin
• [x] publish linux/arm64 git plugin
• [x] publish linux/arm docker plugin
• [x] publish linux/arm64 docker plugin
• [ ] develop strategy for defining multi-platform yaml configurations

cc @firecyberice @sokoow @djmaze

First of all allow me to tell you that I think drone is an exquisite piece of technology that's very easy to understand and use. Thank you for sharing :).

I am trying to deploy drone 0.4 with Postgres Database located in another container.

$ docker run -d --name drone-postgres -e POSTGRES_USER=drone -e POSTGRES_DB=drone -e POSTGRES_PASSWORD=drone postgres

I have verified that the database is up and running with another docker container.

$ docker run -it --link drone-postgres:postgres --rm postgres sh -c 'exec psql -h "$POSTGRES_PORT_5432_TCP_ADDR" -p "$POSTGRES_PORT_5432_TCP_PORT" -U drone'

After entering drone password I am inside a psql shell. I suppose it is working.

Next I have run drone with environment variables.

$ docker run --rm -it -e DATABASE_DRIVER=postgres -e DATABASE_CONFIG=postgres://drone:[email protected]:5432/drone drone/drone:0.4

INFO[0000] using database driver postgres
INFO[0000] using database config postgres://drone:[email protected]:5432/drone
INFO[0000] database ping failed. retry in 1s
INFO[0001] database ping failed. retry in 1s
INFO[0002] database ping failed. retry in 1s
INFO[0003] database ping failed. retry in 1s
INFO[0004] database ping failed. retry in 1s
INFO[0005] database ping failed. retry in 1s
INFO[0006] database ping failed. retry in 1s
INFO[0007] database ping failed. retry in 1s
INFO[0008] database ping failed. retry in 1s
INFO[0009] database ping failed. retry in 1s
INFO[0010] database ping failed. retry in 1s

The IP Address is from docker inspect drone-postgres. Could you please tell what have I done wrong or another way to deploy drone with Postgres, both in docker containers.

The current Gogs implementation works for public (open source) repositories only. We need a way to upload ssh keys to the repository in order to clone. Ideally we would also have a way to see if the key already exists, and either update or delete and re-upload.

We'll need the Gogs team to expose this functionality.

For reference, this is the code we use for GitHub: https://github.com/drone/drone/blob/master/plugin/remote/github/helper.go#L233:L255

@compressed thoughts?

I was playing around with Drone.io over the weekend and I'm really impressed.

However, there is one big issue for our Rails project: Bundling all the Gems (~ 250 Gems, where about 10 of these are git checkouts) takes about 10 minutes for each build, as I've found no way to provide a cacheable directory to Bundler.

I've seen the issues #43 and #143, but as far as I understood the solution proposed in #43, the cache would only be invalidated when the actual setup commands have changed. In my case, it would need to re-run the commands when the content of the project's Gemfile.lock has changed.

Furthermore, it would be neat to be able to share a cache directory between different projects. In our current Jenkins setup, we're sharing a global Bundler directory, which speeds up new project builds enormously.

Here is an excerpt of our build file:

BUNDLE_PATH="$JENKINS_HOME/shared/bundle"
bundle install --path="$BUNDLE_PATH"

Hey guys,

thank you for this great project! It would be awesome to have support for self hosted git repositories. Then drone would be the perfect solution for a enterprise project I'm working on and I could get rid of Jenkins :)

Cheers Sebastian

This is the first go to get Stash/Bitbucket support working(continuation of https://github.com/drone/drone/pull/567). The "happy path" works and there's a bit of clean up (First time I've written anything in golang) but if folks want to try it out or give some feedback on the dos and don'ts I'll update it.

Currently we have the ability to store private environment variables in the database. I'd like to expand this capability to store encrypted environment variables in the yaml itself, similar to travis.

secure:
  docker_user: U2FsdGVkX19g96OdOIRPtVNGzPP1CgGlxRxRVDvlVHZKYrulqPLlYFG3TfUw53Gk
  docker_pass: U2FsdGVkX18B3tY76uPxLe2tA6UzaBrVMMsArAUS4bo=

the secure parameters are decrypted at runtime and injected into your build yaml, similar to how we inject private variables (entered in the UI) or matrix parameters:

deploy:
  docker:
    email: $$docker_user
    password: $$docker_pass

Unlike travis, injecting the private parameters as environment variables is not sufficient since publish, deploy and notify sections (which are typically the only sections that require such secrets) are executed outside of the build container and expect very specific parameters in the yaml. This is a result of the new 0.4 plugin model.

So for now we need to inject using the same syntax as matrix and private variables. I will spend some time, however, thinking up alternate approaches ...

Drone shows the logs until it fails, then it replaces the output of the logs with . . .

exit code 1

It makes it almost impossible to debug my projects when they fail

Support cutom pipeline customization to commit message information, which will help to view associated triggers and debug troubleshooting.

Actual

I create custom build in another pipeline, but I can't see some useful information of these builds on the list.

Expect

I can customize the commit message information when creating custom build, so that it can write the build number triggered by the associated pipeline.

e.g.

# 19  Triggered by build number 15 of root/test
# 18  Triggered by build number 14 of root/test
# 17  Triggered by build number 13 of root/test

I used drone0.8 and update to drone2 now, however I can't see my subgroups repo, but it is ok in drone0.8, even it is ugly. For example, I have a repo /foo/bar/test.git, in drone0.8 it shows like /foo/bar but I can search foo/bar/test.git in repos. However it is doesn't work in drone2, and I see this issue 2009. I like this function although it is ugly.

Not sure if it is the correct place to ask, but since drone-docker does not allow filing issues, I will post my issue here.

https://github.com/drone-plugins/drone-docker/blob/7888a798b1b331bd9c5a2662e50494f907499f2c/card.go#L75-L88

The mapRegistryToURL function uses a simple heuristic to generate URLs for common public registries. But a self-hosted registry using distribution or Gitea will be mapped to invalid URLs. It's desirable to have a general config entry to allow custom mapping using regex substitution mechanism, e.g., with the following configuration

DRONE_DOCKER_REGISTRY_MATCH=<REGEXP>  # Match and capture
DRONE_DOCKER_REGISTRY_REPLACEMENT=<REPLACEMENT>

similar to a simplified version of Prometheus' relabeling config. Or a configuration entry based on template string (if general enough).

There are multiple vulnerabilities within drone images (drone, drone-runniner-kube, drone-vault-extension) as mentioned below.

Is there any plan to address this in future release?

CVE Name | Asset Name | Vulnerability Description | Remediation | Current Version | Recommended Version | DetailedName -- | -- | -- | -- | -- | -- | -- CVE-2022-28391 | docker.io/drone/drone-runner-kube | The package busybox version 1.32.1-r7 was detected in APK package manager on a container image running Alpine 3.13.7 is vulnerable to CVE-2022-28391, which exists in versions < 1.32.1-r8. The vulnerability was found in the Official Alpine Security Advisories with vendor severity: High (NVD severity: High). The vulnerability can be remediated by updating the package to version 1.32.1-r8 or higher, by adding the following command to the Dockerfile: RUN apk upgrade busybox. | apk upgrade busybox | 1.32.1-r7 | 1.32.1-r8 | busybox CVE-2022-0778 | docker.io/drone/drone-runner-kube | The package libcrypto1.1 version 1.1.1l-r0 was detected in APK package manager on a container image running Alpine 3.13.7 is vulnerable to CVE-2022-0778, which exists in versions < 1.1.1n-r0. The vulnerability was found in the Official Alpine Security Advisories with vendor severity: High (NVD severity: High). This vulnerability has a known exploit available. Source: Packetstorm. The vulnerability can be remediated by updating the package to version 1.1.1n-r0 or higher, by adding the following command to the Dockerfile: RUN apk upgrade libcrypto1.1. | apk upgrade libcrypto1.1 | 1.1.1l-r0 | 1.1.1n-r0 | libcrypto1.1 End-of-Life Version of Technology | docker.io/drone/drone-runner-kube | The OS Linux Alpine version 3.13.7 has been End-of-Life since 2022-11-01 as indicated in Alpine Releases. End-of-Life versions of operating systems have no further official support by the vendor and thus no security patches. Furthermore, newly discovered vulnerabilities are not reported. Thus, such technologies pose a threat that is both unknown and will not be fixed. |   | 3.13.7 | 3.14.8 | Linux Alpine End-of-Life Version of Technology | docker.io/drone/drone | The OS Linux Alpine version 3.11.13 has been End-of-Life since 2021-11-01 as indicated in Alpine Releases. End-of-Life versions of operating systems have no further official support by the vendor and thus no security patches. Furthermore, newly discovered vulnerabilities are not reported. Thus, such technologies pose a threat that is both unknown and will not be fixed. |   | 3.11.13 | 3.14.8 | Linux Alpine CVE-2022-30065 | docker.io/drone/drone-runner-kube | The package busybox version 1.32.1-r7 was detected in APK package manager on a container image running Alpine 3.13.7 is vulnerable to CVE-2022-30065, which exists in versions < 1.32.1-r9. The vulnerability was found in the Official Alpine Security Advisories with vendor severity: High (NVD severity: High). The vulnerability can be remediated by updating the package to version 1.32.1-r9 or higher, by adding the following command to the Dockerfile: RUN apk upgrade busybox. | apk upgrade busybox | 1.32.1-r7 | 1.32.1-r9 | busybox CVE-2022-37434 | docker.io/drone/drone-runner-kube | The package zlib version 1.2.11-r3 was detected in APK package manager on a container image running Alpine 3.13.7 is vulnerable to CVE-2022-37434, which exists in versions < 1.2.12-r2. The vulnerability was found in the Official Alpine Security Advisories with vendor severity: Critical (NVD severity: Critical). This vulnerability has a known exploit available. Source: Github [1, 2, 3]. The vulnerability can be remediated by updating the package to version 1.2.12-r2 or higher, by adding the following command to the Dockerfile: RUN apk upgrade zlib. | apk upgrade zlib | 1.2.11-r3 | 1.2.12-r2 | zlib CVE-2022-37434 | docker.io/drone/drone | The package zlib version 1.2.11-r3 was detected in APK package manager on a container image running Alpine 3.11.13 is vulnerable to CVE-2022-37434, which exists in versions < 1.2.11-r4. The vulnerability was found in the Official Alpine Security Advisories with vendor severity: Critical (NVD severity: Critical). This vulnerability has a known exploit available. Source: Github [1, 2, 3]. The vulnerability can be remediated by updating the package to version 1.2.11-r4 or higher, by adding the following command to the Dockerfile: RUN apk upgrade zlib. | apk upgrade zlib | 1.2.11-r3 | 1.2.11-r4 | zlib CVE-2018-25032 | docker.io/drone/drone-runner-kube | The package zlib version 1.2.11-r3 was detected in APK package manager on a container image running Alpine 3.13.7 is vulnerable to CVE-2018-25032, which exists in versions < 1.2.12-r0. The vulnerability was found in the Official Alpine Security Advisories with vendor severity: High (NVD severity: High). The vulnerability can be remediated by updating the package to version 1.2.12-r0 or higher, by adding the following command to the Dockerfile: RUN apk upgrade zlib. | apk upgrade zlib | 1.2.11-r3 | 1.2.12-r0 | zlib CVE-2022-28391 | docker.io/drone/drone-runner-kube | The package ssl_client version 1.32.1-r7 was detected in APK package manager on a container image running Alpine 3.13.7 is vulnerable to CVE-2022-28391, which exists in versions < 1.32.1-r8. The vulnerability was found in the Official Alpine Security Advisories with vendor severity: High (NVD severity: High). The vulnerability can be remediated by updating the package to version 1.32.1-r8 or higher, by adding the following command to the Dockerfile: RUN apk upgrade ssl_client. | apk upgrade ssl_client | 1.32.1-r7 | 1.32.1-r8 | ssl_client End-of-Life Version of Technology | docker.io/drone/vault | The OS Linux Alpine version 3.6.5 has been End-of-Life since 2019-05-01 as indicated in Alpine Releases. End-of-Life versions of operating systems have no further official support by the vendor and thus no security patches. Furthermore, newly discovered vulnerabilities are not reported. Thus, such technologies pose a threat that is both unknown and will not be fixed. |   | 3.6.5 | 3.14.8 | Linux Alpine CVE-2022-0778 | docker.io/drone/drone-runner-kube | The package libssl1.1 version 1.1.1l-r0 was detected in APK package manager on a container image running Alpine 3.13.7 is vulnerable to CVE-2022-0778, which exists in versions < 1.1.1n-r0. The vulnerability was found in the Official Alpine Security Advisories with vendor severity: High (NVD severity: High). This vulnerability has a known exploit available. Source: Packetstorm. The vulnerability can be remediated by updating the package to version 1.1.1n-r0 or higher, by adding the following command to the Dockerfile: RUN apk upgrade libssl1.1. | apk upgrade libssl1.1 | 1.1.1l-r0 | 1.1.1n-r0 | libssl1.1 CVE-2022-30065 | docker.io/drone/drone-runner-kube | The package ssl_client version 1.32.1-r7 was detected in APK package manager on a container image running Alpine 3.13.7 is vulnerable to CVE-2022-30065, which exists in versions < 1.32.1-r9. The vulnerability was found in the Official Alpine Security Advisories with vendor severity: High (NVD severity: High). The vulnerability can be remediated by updating the package to version 1.32.1-r9 or higher, by adding the following command to the Dockerfile: RUN apk upgrade ssl_client. | apk upgrade ssl_client | 1.32.1-r7 | 1.32.1-r9 | ssl_client

i set the docker daemon.json, its means i enable ipv6 at docker.

{
    "ipv6": true,
    "fixed-cidr-v6": "2001:db8:1::/64"
}

also i can run alpine on host with ipv6 successful. but let drone runner docker do it, i don't know how it works, because host docker network bridge not have any 172.19.x.x ip.

            "b86e3bed93598cf767afd89fd3de8cc500d6630c952656ee44a6ac8228396619": {
                "Name": "drone-runner",
                "EndpointID": "37feadaa4f6dfff551d8c5f84eaca478498755c4b2a00642c935f9ca052e434e",
                "MacAddress": "02:42:ac:11:00:05",
                "IPv4Address": "172.17.0.5/16",
                "IPv6Address": "2001:db8:1::242:ac11:5/64"
            }

so I'm trying to figure out what it's doing with /var/run/docker.sock, and it looks like it's creating a completely different docker network and without ipv6.

latest: Pulling from library/alpine
Digest: sha256:bc41182d7ef5ffc53a40b044e725193bc10142a1243f395ee852a8d9730fc2ad
Status: Image is up to date for alpine:latest
+ ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
28: eth0@if29: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 qdisc noqueue state UP 
    link/ether 02:42:ac:13:00:02 brd ff:ff:ff:ff:ff:ff
    inet 172.19.0.2/16 brd 172.19.255.255 scope global eth0
       valid_lft forever preferred_lft forever
+ ping *
PING * (*): 56 data bytes
ping: sendto: Address not available

and i set --env DRONE_RUNNER_NETWORKS=bridge , but its not working. and i use dind to test my guess, i find that runner will create random docker network, so can i control it behavior? Forgive me for my English proficiency in machine translation.