Giter VIP home page Giter VIP logo

charts's Introduction

Gitness

Gitness is an open source development platform packed with the power of code hosting and automated DevOps pipelines.

Overview

Gitness is an open source development platform packed with the power of code hosting and automated continuous integration pipelines.

Running Gitness locally

The latest publicly released docker image can be found on harness/gitness.

To install Gitness yourself, simply run the command below. Once the container is up, you can visit http://localhost:3000 in your browser.

docker run -d \
  -p 3000:3000 \
  -v /var/run/docker.sock:/var/run/docker.sock \
  -v /tmp/gitness:/data \
  --name gitness \
  --restart always \
  harness/gitness

The Gitness image uses a volume to store the database and repositories. It is highly recommended to use a bind mount or named volume as otherwise all data will be lost once the container is stopped.

See docs.gitness.com to learn how to get the most out of Gitness.

Where is Drone?

Gitness represents a massive investment in the next generation of Drone. Where Drone focused on continuous integration, Gitness adds source code hosting, bringing code management and pipelines closer together.

The goal is for Gitness to eventually be at full parity with Drone in terms of pipeline capabilities, allowing users to seemlessly migrate from Drone to Gitness.

But, we expect this to take some time, which is why we took a snapshot of Drone as a feature branch drone (README) so it can continue development.

As for Gitness, the development is taking place on the main branch.

For more information on Gitness, please visit gitness.com.

For more information on Drone, please visit drone.io.

Gitness Development

Pre-Requisites

Install the latest stable version of Node and Go version 1.20 or higher, and then install the below Go programs. Ensure the GOPATH bin directory is added to your PATH.

Install protobuf

  • Check if you've already installed protobuf protoc --version
  • If your version is different than v3.21.11, run brew unlink protobuf
  • Get v3.21.11 curl -s https://raw.githubusercontent.com/Homebrew/homebrew-core/9de8de7a533609ebfded833480c1f7c05a3448cb/Formula/protobuf.rb > /tmp/protobuf.rb
  • Install it brew install /tmp/protobuf.rb
  • Check out your version protoc --version

Install protoc-gen-go and protoc-gen-go-rpc:

  • Install protoc-gen-go v1.28.1 go install google.golang.org/protobuf/cmd/[email protected] (Note that this will install a binary in $GOBIN so make sure $GOBIN is in your $PATH)

  • Install protoc-gen-go-grpc v1.2.0 go install google.golang.org/grpc/cmd/[email protected]

$ make dep
$ make tools

Build

First step is to build the user interface artifacts:

$ pushd web
$ yarn install
$ yarn build
$ popd

After that, you can build the gitness binary:

$ make build

Run

This project supports all operating systems and architectures supported by Go. This means you can build and run the system on your machine; docker containers are not required for local development and testing.

To start the server at localhost:3000, simply run the following command:

./gitness server .local.env

Auto-Generate Gitness API Client used by UI using Swagger

Please make sure to update the autogenerated client code used by the UI when adding new rest APIs.

To regenerate the code, please execute the following steps:

  • Regenerate swagger with latest gitness binary ./gitness swagger > web/src/services/code/swagger.yaml
  • navigate to the web folder and run yarn services

The latest API changes should now be reflected in web/src/services/code/index.tsx

User Interface

This project includes a full user interface for interacting with the system. When you run the application, you can access the user interface by navigating to http://localhost:3000 in your browser.

REST API

This project includes a swagger specification. When you run the application, you can access the swagger specification by navigating to http://localhost:3000/swagger in your browser (for raw yaml see http://localhost:3000/openapi.yaml).

For testing, it's simplest to just use the cli to create a token (this requires gitness server to run):

# LOGIN (user: admin, pw: changeit)
$ ./gitness login

# GENERATE PAT (1 YEAR VALIDITY)
$ ./gitness user pat "my-pat-uid" 2592000

The command outputs a valid PAT that has been granted full access as the user. The token can then be send as part of the Authorization header with Postman or curl:

$ curl http://localhost:3000/api/v1/user \
-H "Authorization: Bearer $TOKEN"

CLI

This project includes VERY basic command line tools for development and running the service. Please remember that you must start the server before you can execute commands.

For a full list of supported operations, please see

$ ./gitness --help

Contributing

Refer to CONTRIBUTING.md

License

Apache License 2.0, see LICENSE.

charts's People

Contributors

agrahamlincoln avatar alaaattya avatar ashwilliams1 avatar bkk-bcd avatar bradrydzewski avatar coryjohnson-flume avatar cyhoon avatar ffafi-polarsquad avatar grachevko avatar gtaylor avatar jeanlucmongrain avatar jimsheldon avatar kameshsampath avatar loeffel-io avatar minazukie avatar nd-brown avatar neelanjan00 avatar pandalec avatar samuelfischer avatar staffanselander avatar tboerger avatar viceice avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar

charts's Issues

DRONE_GITEA_SERVER is missing in value.yml

Hey,

the DRONE_GITEA_SERVER key is missing in the value.yml of the drone chart. After inserting it I can connect to the Gitea Server normally. It's just a documentation thing.

Thank you.

dron runner SA lacks required credentials

after installing drone runners by

helm upgrade drone-runner drone/drone-runner-kube --install --create-namespace --namespace drone --values runner.yaml

with values:

replicaCount: 2
env:
  DRONE_RPC_SECRET: aaaa
  DRONE_NAMESPACE_DEFAULT: drone

I'm getting

default: secrets is forbidden: User "system:serviceaccount:drone:drone-runner-drone-runner-kube" cannot create resource "secrets" in API group "" in the namespace "drone"

when running a pipeline

Update image tags in default values.yaml

I'm not sure if the chart needs other changes, but both the server and the kube runner are pointing to old versions by default (1.6.5 vs 1.7.0 and beta.1 vs beta.3).

Helm charts requires DRONE_RPC_SECRET when it may already be provided by extraSecretNamesForEnvFrom secret

PROBLEM
When providing secrets using the extraSecretNamesForEnvFrom method, helm3 still raises an error that the DRONE_RPC_SECRET environment variable is missing.

STEPS

  1. Create a Kubernetes environment, setup Helm 3, add the drone repo, and update. (I used microk8s for this)
  2. Create a drone namespace.
  3. Create a drone-secret Kubernetes secret in the drone namespace similar to the following...
apiVersion: v1
kind: Secret
metadata:
  name: drone-secret
  namespace: drone
data:
  DRONE_RPC_SECRET: ***
  DRONE_GITHUB_CLIENT_ID: ***
  DRONE_GITHUB_CLIENT_SECRET: ***
  1. Create a values file that makes reference to the secret that looks similar to the following...
service:
  type: LoadBalancer
 
extraSecretNamesForEnvFrom:
  - drone-secret

env:
  DRONE_SERVER_HOST: drone.domain.local
  DRONE_SERVER_PROTO: https
  1. Attempt to install drone using the helm chart using a command similar to the following:
  2. Observe.

OBSERVED
The command returns the following error:

Error: values don't meet the specifications of the schema(s) in the following chart(s):
drone:
- env: DRONE_RPC_SECRET is required

EXPECTED
The DRONE_RPC_SECRET would be pulled from the Kubernetes Secret, so it should not be prompting the user as if it was not already provided.

WORKAROUND
Add a bogus value for the DRONE_RPC_SECRET environment variable in the values.yaml file.

SOLUTION
Remove references to DRONE_RPC_SECRET from the required properties in the values.schema.json file.
This can be done in the following places:

"DRONE_RPC_SECRET"

securityContext example misleading / port 80 hardcoded

the securityContext section in the default values.yaml implies that dropping all capabilities and running as non-root is possible; however this quickly fails because the chart seemingly is hardcoded to have drone listen on port 80.

Missing provider specific configuration

Currently, server chart is too generic and does not support provider specific configurations. Things like DRONE_STASH_PRIVATE_KEY have to be created beforehand and mounted separately.

Perhaps such values could be supplied during installation step. Prior to submitting PR would love to know what are your suggestions regarding chart structure.

Add support for gateway API

The Gateway API has reached v1 and implemenatation are starting to arrive. Please add Gateway API templates to the helm chart that can be selected in lieu of Ingress templates. Thank you!

stuck in state `default: Pending` on gcloud k8s cluster

I tried to follow the steps mentioned here https://github.com/drone/charts.

I created a k8s cluster on gcloud and performed in sequence below steps:

  1. k8s in google cloud I can access from my machine.

  2. I added chart in helm

helm repo add drone https://charts.drone.io
helm repo update
  1. I created drone-values.yaml
service:
  type: LoadBalancer
env:
  DRONE_SERVER_HOST: drone.example.com
  DRONE_SERVER_PROTO: http
  DRONE_RPC_SECRET: secret
  DRONE_GITHUB_CLIENT_ID: xxxxxxxxxxxxxxxxxxxxxxx
  DRONE_GITHUB_CLIENT_SECRET: yyyyyyyyyyyyyyyyyyyyy
  DRONE_USER_CREATE: username:kushwahashiv,admin:true
  1. installed drone
kubectl create ns drone
helm install --namespace drone drone drone/drone -f drone-values.yaml

All the pods were created and running

  1. I created a file rone-runner-kube-values.yaml with below content
rbac:
  buildNamespaces:
    - drone

env:
  DRONE_RPC_SECRET: secret
  DRONE_NAMESPACE_DEFAULT: drone
  1. Installed runner
helm install --namespace drone drone-runner-kube drone/drone-runner-kube -f drone-runner-kube-values.yaml

All the pods running successfully.

  1. When I sync repos and try to change the repo it triggers a build

image

Above build is now stuck for forever in a default: Pending state

I'm not sure which step I'm missing to setup the drone on google cloud.

Issue with deploying Drone Runner on GKE Autopilot - Connection and Permission Errors

Description:
I deployed Drone Runner on GKE Autopilot following the official documentation, and my parameter settings are as follows:

env:
  DRONE_RPC_SECRET: test
  DRONE_SECRET_PLUGIN_ENDPOINT: http://drone-kubernetes-secrets:3000
  DRONE_SECRET_PLUGIN_TOKEN: test
  DRONE_RUNNER_NETWORK_OPTS: "com.docker.network.driver.mtu:12345"
dind: 
  commandArgs:
    - "--host"
    - "tcp://localhost:2375"
    - "--mtu=12345"
  securityContext:
    privileged: false

podSecurityContext:
  fsGroup: 2000
securityContext:
  capabilities:
    drop:
    - ALL
  readOnlyRootFilesystem: true
  runAsNonRoot: true
  runAsUser: 1000

However, when I check the logs of the Runner pod, I encountered the following errors:

grpc: addrConn.createTransport failed to connect to {unix:///var/run/docker/containerd/containerd.sock <nil> 0 <nil>}. Err :connection error: desc = \"transport: Error while dialing dial unix:///var/run/docker/containerd/containerd.sock: timeout\". Reconnecting..." module=grpc
failed to start daemon: Error initializing network controller: error obtaining controller instance: failed to create NAT chain DOCKER: iptables failed: iptables -t nat -N DOCKER: iptables v1.8.9 (legacy): can't initialize iptables table `nat': Permission denied (you must be root)

I'm seeking assistance on how to resolve and adjust the configuration for the mentioned issues.

Thank you.

drone-runner-kube ingress resource does not correctly configure path and pathType

this commit correctly added support for configuring pathType in ingress resources, but did not update the ingress spec to configure path correctly, and did not update the values.yaml to reflect the correct way to configure ingress.

Without these fixes, it's impossible to apply the drone-runner-kube helm chart version 0.1.9 with ingress.enabled set to true. either the server will reject the ingress resource because it's missing pathType, or the ingress path will be configured with path: map[path:/ pathType:Prefix] which is invalid.

If I attempt to apply the ingress resource with an updated values.yaml (including pathType), the ingress resource attempts to change in the following way:

          paths:
-           - path: /
+           - path: map[path:/ pathType:Prefix]
+             pathType: Prefix

If I attempt to apply the chart with the current values.yaml (with path: ["/"]), the ingress resource validation fails with:

Error: Failed to render chart: exit status 1: Error: template: drone-runner-kube/templates/ingress.yaml:46:23: executing "drone-runner-kube/templates/ingress.yaml" at <.pathType>: can't evaluate field pathType in type interface {}

Helm charts hard-coded to use HTTP

USE CASE

My use case is to setup a CICD solution in my homelab for a private repository hosted on Github. When activating a repository, a Github Webhook is created that attempts to preforms an HTTP post operation against my hostname against the /hook path.

PROBLEM

The charts are hard-coded to use the HTTP port instead of HTTPS which is explicitly discouraged by Github for webhooks. Examples of this can be found in the deployment, service, and ingress templates:

ports:
- name: http
containerPort: 80
protocol: TCP

- port: {{ .Values.service.port }}
targetPort: http
protocol: TCP
name: http

- host: {{ .host | quote }}
http:
paths:
{{- range .paths }}
- path: {{ . }}
backend:
serviceName: {{ $fullName }}
servicePort: {{ $svcPort }}
{{- end }}

Because the chart is hard coded for HTTP, it prevents from using other features like DRONE_TLS_AUTOCERT or manually providing TLS certificates to align with Github best practices.

Master chart 1.1.5 while published chart is 1.1.3

First off, loving Drone and I like that you've taken ownership of maintaining a repo to properly deploy Drone to Kubernetes, with all the bells and whistles.

I found an issue trying to migrate from community charts to this one. When I went to deploy it to a sandbox to test out values, helm was unable to find the version of the chart pointed to by the master branch, 1.1.5. When reading the published chart repo index, I see the only chart version published for the drone server chart is 1.1.3.

Has the CI publish job not run?

Can't deploy drone helm chart on EKS

I've configured drone helm chart and when deploy it, right away fails

No clear error output, why it's failing.
Error logs:

{"level":"fatal","msg":"main: source code management system not configured","time":"2024-02-21T19:53:09Z"}

What am I missing any suggestions?

Can't attach extra volumes to docker-runner

Why is there no ability to define and attach extra volumes to the docker-runner deployment?

I want to use the DOCKER_RUNNER_ENV_FILE environment variable to inject environment variables into the pipelines.

I'd like to define things like a Docker registry mirror, custom DNS servers, etc.

I see there are appropriate fields in the values schema, but they're not used in the docker-runner deployment.

Edit: I want to use a file, rather than the available DOCKER_RUNNER_ENV environment variable, because in fields like the Docker registry mirror URL there are colons, which are not parsed correctly when provided through this variable.

Breaking environment

Upgrading to 0.5.0 (commit f058f76) is breaking our whole system with drone chart 0.4.0 and droner-runner-kube chart 0.1.9

the drone-runner-kube can't ping the remote server anymore

Invalid healthz

Hey, pretty unsure about this but is http://:http/healthz expected at the deployment because my gke health checks are not working (same result local and on gke)

Containers:
   server:
    Image:      drone/drone:2.11.1
    Port:       80/TCP
    Host Port:  0/TCP
    Liveness:   http-get http://:http/healthz delay=0s timeout=1s period=10s #success=1 #failure=3
    Readiness:  http-get http://:http/healthz delay=0s timeout=1s period=10s #success=1 #failure=3

Running the drone-runner as a daemonset

Hello! Drone is great and these helm charts are incredibly useful. This is a question, not an issue.

I changed the drone-runner helm chart from a Deployment to a DaemonSet and I was wondering if there were any downsides of doing this?

Due to the number of resources I need for my pipelines, our cluster autoscaler is busy and nodes are always coming up and going down.

This sticks out in the docs to me

The Kubernetes runner must not be restarted while pipelines are running. If you stop or restart the runner while a pipeline is running, it will be stuck in a running state, and the associated Pod must be manually removed.

I wanted to try a DaemonSet in the hopes that there are always enough runners available and that they wont get rescheduled with all of the autoscaling happening.

So far the only issue I've encountered has been needing to refresh a few times to get the drone-runner UI to load.

Aside from that, are there any gotchas I should be aware of with this approach?

Improve Documentation

Improve Documentation to add details on how to configure the secrets that is used in the helm values.

Charts deprecated

I've seen that drone v2.0.0 has been released, but the chart version has since more than a year not been updated. Are the charts deprecated or orphaned?

Maybe an update of the helm charts are required to deploy drone v2.0 in a kubernetes cluster.

Build fails with spec.containers[2].volumeMounts[0].mountPath: Required value

I have setup a server and runner with the following configs:

drone-values.yml (server)

env:
  DRONE_SERVER_HOST: drone.mydomain.com
  DRONE_SERVER_PROTO: http
  DRONE_RPC_SECRET: mysecret

  DRONE_GITHUB_CLIENT_ID: myid
  DRONE_GITHUB_CLIENT_SECRET: mysecret
  DRONE_USER_CREATE: username:myuser,admin:true

drone-runner-kube-values.yaml (runner)

rbac:
  buildNamespaces:
    - drone

env:
  DRONE_RPC_SECRET: mysecret

  DRONE_NAMESPACE_DEFAULT: drone

when drone gets the webhook call from github for a push, the build fails with:
default: Pod "drone-lcomzc0dunq7m0nr5oea" is invalid: spec.containers[2].volumeMounts[0].mountPath: Required value

Capture

I see that I have a persistent volume claim created and connected to the drone/drone image.

Please help me troubleshoot this issue.

Here's my config for the project:
Capture

Wrong image urls

It seems the https://drone.io/apple-touch-icon.png image no longer exists.

error getting logo image https://drone.io/apple-touch-icon.png: unexpected status code received: 404 (package: drone version: 0.2.5)
error getting logo image https://drone.io/apple-touch-icon.png: unexpected status code received: 404 (package: drone-kubernetes-secrets version: 0.1.2)
error getting logo image https://drone.io/apple-touch-icon.png: unexpected status code received: 404 (package: drone-runner-docker version: 0.1.0-rc.3)
error getting logo image https://drone.io/apple-touch-icon.png: unexpected status code received: 404 (package: drone-runner-kube version: 0.1.8)

https://artifacthub.io/control-panel/repositories?modal=tracking&user-alias=&org-name=drone&repo-name=drone

Is this project active?

I see that the app version used by this chart is lagging behind the releases of harness/drone by a year. Should this chart be considered deprecated/archived?

If so, please clarify that in the README and perhaps mark the repo as archived in GitHub.

If not, please update the chart. ๐Ÿ˜„

I was going to ask on Slack, but that's apparently locked down to Harness employees only.

clone takes 3 mins

Sometimes the clone plugin takes 3 mins (drone-runner-kube). Is there anything i can debug?

Bildschirmfoto 2022-06-02 um 19 08 05

Chart for vault-secrets

First of all thank you for providing your own helm-chart repository. Recently we've migrated to this one from "stable".

Are there any plans to add a chart for vault-secrets?

Chart stores secrets in ConfigMap rather than Secret

Values such as DRONE_DATABASE_SECRET, DRONE_RPC_SECRET, DRONE_GITEA_CLIENT_SECRET (and similar such secrets from other providers) are stored in a ConfigMap rather than a K8s Secret.

I understand I can use extraSecretNamesForEnvFrom and pass my own pre-created secret, but of course the value proposition of the Helm chart is that it creates K8s resources for me. I use the Helm Secrets plugin that allows security passing secret values into Helm charts, and I'd prefer to use this mechanism for Drone secrets as well, rather than manually create a secret outside the chart.

Perhaps a separate envSecrets in the Helm chart, to facilitate this? Something like:

env:
  DRONE_SERVER_HOST: drone.example.com
  DRONE_SERVER_PROTO: https
  DRONE_GITEA_SERVER: https://git.examle.com
  DRONE_GITEA_CLIENT_ID: 9e145da5-692b-42a1-999b-3f09b103906c

envSecrets:
  DRONE_DATABASE_SECRET: d6a7835fd429a27e3f96fc64962f7b0c
  DRONE_RPC_SECRET: c9da1cd55e4f57c6026a0cf47d94f5b7
  DRONE_GITEA_CLIENT_SECRET: +1dV0BB024M/qkIrwPqO5J27tG7WhOCX3d3tXmqPMes=

Or, maybe the chart could be clever enough to automagically place everything matching *_SECRET into a k8s secret.

Happy to submit a PR if you'd accept it.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.