Alternative source for .drone.yml

Ideas
1

I’m attempting to use drone to build an unofficial version of a project on every release. To do this, my Gitea instance mirrors the repository of that project, which allows me to trigger a build on release. However, that project does not use Drone, and as such, does not have a .drone.yml file, and I can’t create one, since Gitea mirrors are read-only. To work around this, it would be great if the Configuration field in the repository settings in the panel could accept a URL to a file, instead of just the path within the repository. That way, I could put my .drone.yml file in a completely different repository, or anywhere else in fact.
Alternatively, is there any already-existent way to do something like this?

2

If you want to change the default behavior for sourcing configuration, you can create a configuration extension. See Configuration Extension | Drone

3

I’m not sure if I understand the idea fully, so correct me if I’m wrong, but this way sounds very overkill for a single repository. Essentially, this means I run another container/server which receives requests on every build for every repo and responds with a config if it’s that repo (or 204 otherwise), correct? Assuming that’s the case, it would make the setup a lot more complicated compared to just serving the file from a standard webserver and pointing Drone at it for that particular repo. Maybe the latter could be considered as a possible feature in a future update?

4

Essentially, this means I run another container/server which receives requests on every build for every repo and responds with a config if it’s that repo (or 204 otherwise), correct?

Correct, you can create an extension, which is essentially a simple microservice, to change Drone’s default behavior for fetching configuration files.

it would make the setup a lot more complicated

It adds a small amount of complexity to your configuration, but this should be quite manageable:

version: "3.8"
services:
    drone:
        image: drone/drone:latest
        ports:
        - "8080:80"
        environment:
+       - DRONE_YAML_ENDPOINT=http://extension:8080
+       - DRONE_YAML_SECRET=bea26a2221fd8090ea38720fc445eca6
        volumes:
        - ./data:/data
+   extension:
+       image: u9123/drone-config-extension
+       environment:
+       - DRONE_SECRET=bea26a2221fd8090ea38720fc445eca6

Maybe the latter could be considered as a possible feature in a future update

Our policy is that these types of features should start as extensions. If the extension gains enough adoption in the community we can consider adding the functionality to Drone core. As a point of reference, the Jsonnet and Starlark capabilities both started as extensions were eventually promoted to core features.

5

I see. The complexity I was referring to was mostly to do with creating and maintaining a custom extension as opposed to configuring Drone to use it, though that plays a part too. Regardless, I’ll take a look at that, since it should be simple enough to implement, and hopefully it’ll one day become a core feature. Thanks for the help!