[{"_1":2,"_172":-5,"_173":-5},"loaderData",{"_3":4,"_13":14,"_21":22,"_151":152},"root",{"_5":-5,"_6":-7,"_7":8,"_9":-7,"_10":11,"_12":-7},"currentUser","primaryEmail","siteVerification","6LeIxAcTAAAAAJcZVRqyHh71UMIEGNQ_MXjiZKhI","toast","enableDev",false,"incidentStatus","routes/_layout",{"_15":-5,"_16":17,"_18":17,"_19":11,"_20":11},"username","isAskGordonEnabled",true,"isUsingNewTemplate","showMinimalLanding","showHoneypotTrap","routes/_layout.r.$namespace.$reponame",{"_23":24,"_25":-5,"_26":11,"_27":11,"_28":29,"_30":31,"_32":-5,"_33":11,"_34":35,"_84":85,"_104":105,"_142":-5,"_143":11,"_144":17,"_145":11,"_146":-5,"_147":11,"_148":-5,"_149":150},"canonicalUrl","https://hub.docker.com/r/dronelab/gitea-release/tags","mcpServer","canSeeDockerfile","canSeeAutobuilds","namespace","dronelab","reponame","gitea-release","cloudBuildSource","isAutobuildsAvailable","repo",{"_36":37,"_38":39,"_41":42,"_43":44,"_45":11,"_46":47,"_48":49,"_50":51,"_53":31,"_28":29,"_54":55,"_56":40,"_57":58,"_59":60,"_61":62,"_63":-5,"_64":58,"_65":66,"_67":11,"_68":29,"_69":70,"_75":17,"_76":77,"_81":29,"_82":83},"categories",[],"content_types",[40],"image","date_registered","2018-10-08T15:54:22.156478Z","description","dronelab gitea-release plugin","is_private","last_updated","2021-12-08T07:06:48.539299Z","last_modified","2024-10-16T13:48:34.145251Z","media_types",[52],"application/vnd.docker.container.image.v1+json","name","pull_count",634,"repository_type","star_count",0,"status",1,"status_description","active","source","collaborator_count","full_description","## Dronelab\n\nDronelab is a wrapper and a set of Docker images to let you use [Drone CI plugins](http://plugins.drone.io/) in your Gitlab CI pipeline.\n\n- [Dronelab](#dronelab)\n- [Basic usage](#basic-usage)\n - [Providing parameters as single yaml variable](#providing-parameters-as-single-yaml-variable)\n - [Providing parameters as parameter to `dronelab` command](#providing-parameters-as-parameter-to-dronelab-command)\n - [Secrets and creating plugin variables directly](#secrets-and-creating-plugin-variables-directly)\n - [Priority of parameters](#priority-of-parameters)\n- [Differences from Drone usage](#differences-from-drone-usage)\n - [Artifacts between steps](#artifacts-between-steps)\n- [How it works](#how-it-works)\n- [Get in touch](#get-in-touch)\n\n## Basic usage\n\nWe'll use [Download plugin](http://plugins.drone.io/drone-plugins/drone-download/) as an example here, but the same patterns should apply to any other image. Here's the most basic use case in Drone:\n\n```yaml\n#.drone.yml\npipeline:\n download:\n image: plugins/download\n source: https://example.com/file.tar.gz\n```\n\nWith Dronelab you can do something similar in your [.gitlab-ci.yml](https://docs.gitlab.com/ce/ci/yaml/) file:\n\n```yaml\ndownload:\n image: dronelab/download\n script: dronelab\n variables:\n source: https://example.com/file.tar.gz\n```\n\nNow this is a bit more chatty due to the way Gitlab CI pipeline is defined, but it mimics the logic close enough that you can follow the [upstream documentation](http://plugins.drone.io/drone-plugins/drone-download/) easily. Essentially the only difference is that we provide the parameters as environment variables and we use the [dronelab version of the image](https://hub.docker.com/u/dronelab/). We also need to provide a `script: dronelab` parameter because `script` is mandatory part of job definition in Gitlab CI.\n\nThis simple approach will work in most cases, however there are some exceptions. That's why there are other ways to provide the parameters with dronelab:\n\n### Providing parameters as single yaml variable\n\nYou can provide plugin parameters as yaml string inside the `plugin` variable:\n\n```yaml\ndownload:\n image: dronelab/download\n script: dronelab\n variables:\n plugin: |\n source: https://example.com/file.tar.gz\n```\n\nNotice the pipe (`|`) character after `plugin:`, this way we can provide yaml as a string in the `plugin` environment variable. This format looks a bit more complicated, but it works better in some cases where using variables isn't an option - for example when you need to provide objects rather than a simple string. Let's see cloudformation plugin as an example:\n\n```yaml\n#.drone.yml\npipeline:\n deploy:\n image: robertstettner/drone-cloudformation\n stackname: my-awesome-stack\n template: templates/stack.yml\n params:\n Version: 123\n Environment: staging\n```\nIn `.gitlab-ci.yml` file we can't define the `params` variable like that, because `variables` only accepts simple strings as value. That's were `plugin` variable can help us:\n\n```yaml\nawscf:\n image: dronelab/cloudformation\n script: dronelab\n variables:\n stackname: my-awesome-stack\n template: templates/stack.yml\n plugin: |\n params:\n Version: 123\n Environment: staging\n```\n\n⚠ Notice, that we can also combine different methods of providing the parameters.\n\n### Providing parameters as parameter to `dronelab` command\n\nIn some cases you might not want to use the `variables` at all. One example is when you use [yaml anchors](https://docs.gitlab.com/ce/ci/yaml/#anchors) and you don't want to override `variables` set in your anchor. Instead you can also provide plugin parameters as `-p` option to the `dronelab` command:\n\n```yaml\n.awscf-template: &cftemplate\n image: dronelab/cloudformation\n variables:\n template: templates/stack.yml\n plugin: |\n params:\n Version: 123\n Environment: staging\n\nstackone:\n <<: *cftemplate\n script: dronelab -p stackname stackone\n\nstacktwo:\n <<: *cftemplate\n script: dronelab -p stackname stacktwo\n```\nHere you can see us creating yaml anchor first to create a template for `cloudformation` plugin with all the common parameters set. Then we use that anchor to define actual jobs, that each work with different stack names.\n\nThe format of the parameter is `-p `. You can provide it multiple times, in that case it might be easier to use yaml [folded style](http://yaml.org/spec/1.2/spec.html#id2796251) syntax:\n\n```yaml\nstackthree:\n <<: *cftemplate\n script: >\n plugin\n -p stackname stacktwo\n -p region eu-west-1\n -p mode createOrUpdate\n```\n\n⚠ Note that this example with anchors is somewhat artificially constructed, you can use [`extends` keyword](https://docs.gitlab.com/ce/ci/yaml/#extends) instead - that one is able to merge your variables.\n\n### Secrets and creating plugin variables directly\n\nWhen you define plugin parameter via `variables`, `plugin` yaml variable or as a parameter via the `-p` script argument, Dronelab will automatically [transform such variables](#how-it-works) into the `PLUGIN_VARIABLE_NAME` environment variable, because that's how Drone plugins actually work. That also means we can provide such variables directly - either via `variables` in the `.gitlab-ci.yml` file or as variables configured via CI/CD settings of the project or on the group level.\n\nYou might have noticed in the Drone plugin documentation, that some plugins accept secrets as form of configuration. These are expected in slightly different format by the Drone plugin. They are simply uppercase version of the secret name without the `PLUGIN_` prefix. Because of that you can't use `plugin` yaml variable, lowercase `variables` variable or `-p` script argument to set these as Dronelab would add the prefix to the name. In most cases you want to provide secrets as CI/CD variables defined in the CI/CD configuration rather than from the `.gitlab-ci.yml` file. (Committing secrets into your repository is generally a bad idea)\n\nLet's look at the [Matrix plugin](http://plugins.drone.io/drone-plugins/drone-matrix/) as an example. You can provide the password either as a `password` parameter or `matrix_password` secret. That means that behind the scenes plugin expects either `PLUGIN_PASSWORD` or `MATRIX_PASSWORD` variable to be set. Let's assume we have set the password in the [Variables CI/CD configuration](https://docs.gitlab.com/ce/ci/variables/README.html#variables) for the project (or group) under the name `MATRIX_PASSWORD`.\n\nHere's how you can send the message to the Matrix room using the saved password:\n\n```yaml\nmessage-one:\n image: dronelab/matrix\n script: dronelab\n variables:\n username: matrix_user\n homeserver: https://matrix.org\n roomid: abcdefghijklmnopqrstuvwxyz:matrix.org\n template: Hello from Gitlab!\n```\n\nNotice we didn't provide the password at all! Gitlab CI will set the variable `MATRIX_PASSWORD` automatically, because it's configured in project settings. Plugin will just use it.\n\nHowever if you want to be more explicit in the `.gitlab-ci.yml` file, you can explicitly provide it:\n\n```yaml\nmessage-two:\n image: dronelab/matrix\n script: dronelab\n variables:\n username: matrix_user\n password: $MATRIX_PASSWORD\n homeserver: https://matrix.org\n roomid: abcdefghijklmnopqrstuvwxyz:matrix.org\n template: Hello from Gitlab!\n```\n\nSending a message to a room might be used multiple times in the pipeline, so you can either use template with yaml anchors, [`extends`](https://docs.gitlab.com/ce/ci/yaml/#extends) keyword or you can just set the variables globally so there's only one place to change them:\n\n```yaml\nvariables:\n username: matrix_user\n password: $MATRIX_PASSWORD\n homeserver: https://matrix.org\n roomid: abcdefghijklmnopqrstuvwxyz:matrix.org\n\nmessage-one:\n image: dronelab/matrix\n script: dronelab\n variables:\n template: Hello from Gitlab!\n\nmessage-two:\n image: dronelab/matrix\n script: dronelab\n variables:\n template: Hello again!\n\n# You can also override some of the global variables to message to a different\n# room for example.\nmessage-elsewhere:\n image: dronelab/matrix\n script: dronelab\n variables:\n roomid: someotherroomidprovidedhere:matrix.org\n template: Hello in a different room!\n```\n\n### Priority of parameters\n\nIn case you provide the same parameter via multiple different ways, they are applied in specific order, the last one applies:\n\n 1. Variables and secrets provided directly as `PLUGIN_VARIABLE_NAME` or `NAME_OF_SECRET`\n 2. Individual variables using `variables`\n 3. The `plugin` yaml variable\n 4. The script parameter via `-p `\n\nThat means the following configuration will download version 1 of the file:\n\n```yaml\ndownload:\n image: dronelab/download\n script: dronelab -p source https://example.com/file_version_1.gz\n variables:\n source: https://example.com/file_version_2.gz\n plugin: |\n source: https://example.com/file_version_3.gz\n```\n\nThis would download version 3:\n\n```yaml\ndownload:\n image: dronelab/download\n script: dronelab\n variables:\n source: https://example.com/file_version_2.gz\n plugin: |\n source: https://example.com/file_version_3.gz \n```\n\n## Differences from Drone usage\n\n### Artifacts between steps\n\nIn Drone all plugins work on top of the same workspace, so for example files downloaded by `download` plugin are automatically available to the next steps in pipeline. If you have Gitlab cache enabled globally, it behaves in similar fashion, however if you have caches disabled you might need to explicitly configure `cache` or `artifacts` (whatever feels more appropriate) to pass the generated content to next job.\n\n## How it works\n\nDronelab plugins should work with any executor, that [supports the `image` keyword](https://docs.gitlab.com/runner/executors/README.html#compatibility-chart). Currently that means you can use the Docker, Docker Machine, Docker Machine SSH and Kubernetes executors.\n\nDronelab plugin image is created by taking the upstream plugin image and wrapping it in `alpine` image with `dronelab` binary added. The alpine image is used as Gitlab CI needs something capable running bash scripts.\n\nThe `dronelab` wrapper then reads provided parameters and environment variables and attempts to translate those to the format expected by Drone plugins. It also attempts to translate [predefined variables](https://docs.gitlab.com/ce/ci/variables/README.html#predefined-variables-environment-variables) to the format expected by Drone.\n\nWhen all variables are created, dronelab will try to execute binary defined in `DRONELAB` environment variable. That one is usually already defined in the Dronelab plugin image and points to the upstream plugin binary.\n\n⚠ Note, that not all variables that are normally available in Drone build environment are currently available in the Dronelab environment. Some are not provided by Gitlab CI, some don't even have their counterpart in the Gitlab word. Some variables have slightly different format. Most plugins use just very small subset of these variables and hence most should work just fine.\n\n## Get in touch\n\nTo report a bug or ask a question, please [open an issue](https://github.com/mprasil/dronelab/issues/new).","has_starred","hub_user","immutable_tags_settings",{"_71":11,"_72":73},"enabled","rules",[74],".*","is_automated","permissions",{"_78":17,"_79":11,"_80":11},"read","write","admin","user","storage_size",39407887,"orgData",{"_86":87,"_88":89,"_90":91,"_92":29,"_93":94,"_95":94,"_96":94,"_97":94,"_98":99,"_100":94,"_101":94,"_102":94,"_103":17},"id","fdfa7ead30bf43a1a49440338976ef28","uuid","fdfa7ead-30bf-43a1-a494-40338976ef28","type","organization","orgname","full_name","","location","company","profile_url","date_joined","2018-10-08T10:28:39.330255Z","gravatar_url","gravatar_email","badge","is_active","recentTags",[106],{"_107":40,"_108":109,"_110":111,"_86":112,"_113":114,"_46":131,"_132":109,"_133":29,"_134":52,"_53":135,"_136":137,"_138":122,"_139":131,"_140":62,"_141":17},"content_type","creator",4258026,"full_size",10173788,37087442,"images",[115],{"_116":117,"_118":119,"_120":94,"_121":122,"_123":124,"_125":126,"_127":94,"_128":-5,"_129":111,"_59":62,"_130":-5},"architecture","amd64","digest","sha256:61100314ebd4fe6333fdcf791b63bf61d60b15865f9713a8fd277dc771d38ee7","features","last_pulled","2026-09-23T10:28:01.344827089Z","last_pushed","2021-12-08T07:06:49Z","os","linux","os_features","os_version","size","variant","2021-12-08T07:06:48.225053Z","last_updater","last_updater_username","media_type","latest","repository",6120578,"tag_last_pulled","tag_last_pushed","tag_status","v2","sbxKitMetadata","isPotentialSpam","isHubSbxKitsEnabled","showSbxLogoOverride","sbxTrademarkText","displaySecurityMetadata","tagAttestations","tagsHaveAttestations",[],"routes/_layout.r.$namespace.$reponame.tags",{"_34":153,"_160":161,"_149":170,"_171":11},{"_36":154,"_38":155,"_41":42,"_43":44,"_45":11,"_46":47,"_48":49,"_50":156,"_53":31,"_28":29,"_54":55,"_56":40,"_57":58,"_59":60,"_61":62,"_63":-5,"_64":58,"_65":66,"_67":11,"_68":29,"_69":157,"_75":17,"_76":159,"_81":29,"_82":83},[],[40],[52],{"_71":11,"_72":158},[74],{"_78":17,"_79":11,"_80":11},"tags",{"_162":60,"_163":-5,"_164":-5,"_165":166},"count","next","previous","results",[167],{"_107":40,"_108":109,"_110":111,"_86":112,"_113":168,"_46":131,"_132":109,"_133":29,"_134":52,"_53":135,"_136":137,"_138":122,"_139":131,"_140":62,"_141":17},[169],{"_116":117,"_118":119,"_120":94,"_121":122,"_123":124,"_125":126,"_127":94,"_128":-5,"_129":111,"_59":62,"_130":-5},[],"canDeleteTags","actionData","errors"]

dronelab/gitea-release

Tags for dronelab/gitea-release