Feature Requests

Currently, our deployment logs for certain steps are larger then 2mb causing the drone job to not be marked as 'completed' when the step itself has. Therefore the drone pipeline for this job, remains in a continuos running state and never ends. We can implement various work around, but it would be beneficial to have log size limits to not be hard coded and be soft coded environmental value we can set.

Currently, the DroneCI pipeline returns only one status to GitHub PR for example my-org/drone-ci/pr . It is AND logic. It will be success if ALL steps finish successfully, or fail if ANY step fails. To have more granular control over PR checks (optional vs required) every step should be able to return its own status (if no status is defined it should contribute to the base pr checks status - my-org/drone-ci/pr ). As of today, this can be accomplished only with 3rd part plugins (ex: jmccann/drone-github-status ). This should be moved to droneCI native pipeline definition. Example usage: kind: pipeline type: docker name: go-pr-additional-test ​ steps: - name: test-1 image: alpine check-context: my-org/drone-ci/pr/test-1 commands: - echo "Hello world" - name: test-2 image: alpine check-context: my-org/drone-ci/pr/test-2 commands: - echo "Hello world" - exit 1 - name: test-3 image: alpine check-context: my-org/drone-ci/pr/test-3 commands: - echo "Hello world"

Expected: when approval is needed due to conditions being met for one thread, the pipeline is halted until approval given, then, all threads proceed. Observed: Only the thread that initiated the approval is continuing after approval is given, leaving all other threads in a hung state unable to continue. This issue is with Drone CI

Need to use [action trigger] for pipeline to run once a PR has been ready for review, something like b trigger: event: pull_request action: include: opened ready_for_review https://github.com/drone/go-scm/blob/beec4da794fbd87a283154e2bd938d4c63ef785f/scm/driver/github/webhook.go#L175

Add the missing capability to use Organizational Secrets and Templates with BitBucket Datacenter. What we need is that the administrators of the Projects in Bitbucket (the same concept of organization in Github or Group in gitlab, a group of repositories) have privileges to manage the Organization Secrets and Templates without the need to become Drone Administrators (essentially to scale the service to different teams, without the permissions to manage users, etc..).

Using Github Enterprise you can now create custom repository roles, granting access to managing webhooks. This would allow Drone users to activate pipelines without having admin permissions increasing security as we would not need to grant everyone admin access everywhere.

Drone appears to send a SIGKILL to containers when a build is cancelled. This means that processes are unable to terminate cleanly. so user wanted that be changed to send a SIGTERM instead so that processes can handle it and terminate cleanly.The SIGKILL could be sent if containers are still running after a certain timeout.

If user could have a direct link that opens this window with all of these variables pre-filled in through the query string params. Currently, the create promotion API is too limiting to use as it's POST only and trying to initiate this call externally will not preserve the permissions of the user trying to create a promotion.

Hi Harness Support Team, We have an interest in Drone catching the "closed" event from Github Pull Requests ( https://github.com/harness/drone/issues/1878 ) There are teams at the company starting to build more complex pipelines that could be simplified if this was implemented. Let us know if you need any other information. Always happy to collaborate on the feature. Thanks,

DRONE_STEP_NUMBER environment variable https://docs.drone.io/pipeline/environment/reference/drone-step-number/ is not set for pipelines executing on drone-runner-kube. It also does not exist in /run/drone/env. Harness team took an initial look and asked me to create this ticket.