Git with a cup of tea, painless self-hosted git service

Overview

Gitea

Gitea - Git with a cup of tea

View the chinese version of this document

Purpose

The goal of this project is to make the easiest, fastest, and most painless way of setting up a self-hosted Git service. Using Go, this can be done with an independent binary distribution across all platforms which Go supports, including Linux, macOS, and Windows on x86, amd64, ARM and PowerPC architectures. Want to try it before doing anything else? Do it with the online demo! This project has been forked from Gogs since 2016.11 but changed a lot.

Building

From the root of the source tree, run:

TAGS="bindata" make build

or if sqlite support is required:

TAGS="bindata sqlite sqlite_unlock_notify" make build

The build target is split into two sub-targets:

  • make backend which requires Go 1.13 or greater.
  • make frontend which requires Node.js 10.13 or greater.

If pre-built frontend files are present it is possible to only build the backend:

TAGS="bindata" make backend

Parallelism is not supported for these targets, so please don't include -j <num>.

More info: https://docs.gitea.io/en-us/install-from-source/

Using

./gitea web

NOTE: If you're interested in using our APIs, we have experimental support with documentation.

Contributing

Expected workflow is: Fork -> Patch -> Push -> Pull Request

NOTES:

  1. YOU MUST READ THE CONTRIBUTORS GUIDE BEFORE STARTING TO WORK ON A PULL REQUEST.
  2. If you have found a vulnerability in the project, please write privately to [email protected]. Thanks!

Further information

For more information and instructions about how to install Gitea, please look at our documentation. If you have questions that are not covered by the documentation, you can get in contact with us on our Discord server or create a post in the discourse forum.

We maintain a list of Gitea-related projects at gitea/awesome-gitea.
The hugo-based documentation theme is hosted at gitea/theme.
The official Gitea CLI is developed at gitea/tea.

Authors

Backers

Thank you to all our backers! 🙏 [Become a backer]

Sponsors

Support this project by becoming a sponsor. Your logo will show up here with a link to your website. [Become a sponsor]

FAQ

How do you pronounce Gitea?

Gitea is pronounced /ɡɪ’ti:/ as in "gi-tea" with a hard g.

Why is this not hosted on a Gitea instance?

We're working on it.

License

This project is licensed under the MIT License. See the LICENSE file for the full license text.

Screenshots

Looking for an overview of the interface? Check it out!

Dashboard User Profile Global Issues
Branches Web Editor Activity
New Migration Migrating Pull Request View
Pull Request Dark Diff Review Dark Diff Dark
Issues
  • Kanban board

    Kanban board

    Fixes https://github.com/go-gitea/gitea/issues/3476

    • [x] Move Issues between Boards
    • [x] add Project to current Issue
    • [x] view project
    • [x] create a project
    • [x] create Issue during viewing project
    • [x] select project during create Issue
    • [x] add Board to an existing Project
    • [x] delete Board from a project
    • [x] rename Board title
    • [x] Individual boards
    • [x] Organization boards
    • [x] Repository boards

    Definitely another PR:

    • [x] Location of cards in the project board. Right now, cards location in a board cannot be persisted - i.e move card X above card Y in the same board.

    @rudineirk UI suggestion ( from https://github.com/go-gitea/gitea/issues/3476#issuecomment-416950682 ) was used.

    Screen Shot 2020-03-17 at 23 31 20 Screen Shot 2020-03-17 at 23 31 41 Screen Shot 2020-03-17 at 23 31 51

    image

    image

    kind/feature lgtm/need 1 changelog 
    opened by adelowo 233
  • Support unicode emojis and remove emojify.js

    Support unicode emojis and remove emojify.js

    This PR replaces all use of emojify.js and adds unicode emoji support to various areas of gitea.

    This works in a few ways:

    First it adds emoji parsing support into gitea itself. This allows us to

    • Render emojis from valid alias (:smile:)
    • Detect unicode emojis and let us put them in their own class with proper aria-labels and styling
    • Easily allow for custom "emoji"
    • Support all emoji rendering and features without javascript
    • Uses plain unicode and lets the system render in appropriate emoji font
    • Doesn't leave us relying on external sources for updates/fixes/features

    That same list of emoji is also used to create a json file which replaces the part of emojify.js that populates the emoji search tribute.

    For custom "emoji" it uses a pretty simple scheme of just looking for /emojis/img/name.png where name is something a user has put in the "allowed reactions" setting we already have. The gitea reaction that was previously hard coded into a forked copy of emojify.js is included and works as a custom reaction under this method.

    The emoji data sourced here is from https://github.com/github/gemoji which is the gem library Github uses for their emoji rendering (and a data source for other sites). So we should be able to easily render any emoji and :alias: that Github can, removing any errors from migrated content. They also update it as well, so we can sync when there are new unicode emoji lists released.

    I've included a slimmed down and slightly modified forked copy of https://github.com/knq/emoji to make up our own emoji module. The code is pretty straight forward and again allows us to have a lot of flexibility in what happens.

    I had seen a few comments about performance in some of the other threads if we render this ourselves, but there doesn't seem to be any issue here. In a test it can parse, convert, and render 1,000 emojis inside of a large markdown table in about 100ms on my laptop (which is many more emojis than will ever be in any normal issue). This also prevents any flickering and other weirdness from using javascript to render some things while using go for others.

    Includes the optional download of a fallback emoji webfont for small number of users who don't already have one installed.

    Fixes: https://github.com/go-gitea/gitea/issues/9182 Fixes: https://github.com/go-gitea/gitea/issues/8974 Fixes: https://github.com/go-gitea/gitea/issues/8953 Fixes: https://github.com/go-gitea/gitea/issues/6628 Fixes: https://github.com/go-gitea/gitea/issues/5130

    kind/enhancement kind/ui lgtm/done kind/build 
    opened by mrsdizzie 138
  • Provide releases and deb/rpm packages via Bintray

    Provide releases and deb/rpm packages via Bintray

    I would like to integrate a proper process to create real system packages and distribute them via Bintray, than users can just add a deb/rpm repository and got a clean upgrade path.

    Beside that we can also publish our releases to a static page or also to Bintray for download.

    kind/deployment kind/build reviewed/confirmed 
    opened by tboerger 113
  • Auto merge pull requests when all checks succeeded via API

    Auto merge pull requests when all checks succeeded via API

    This adds the functionality to auto merge a pull request, once all status checks succeed.

    To achieve this, it schedules a pr to merge when a user request a merge via API and set merge_when_checks_succeed to true. On every status check update, if there are scheduled merge requests for this pull and that pull pass all merge requirements, they get merged.

    I created fake statuses for testing by running curl -X POST "http://localhost:3000/api/v1/repos/kolaente/testing/statuses/ccd425c09136a411236830785c41afdc172e8208" -H "accept: application/json" -H "authorization: Basic a29sYWVudGU6anVwMjAwMA==" -H "Content-Type: application/json" -d '{"context": "test/context", "description": "description", "state": "pending", "target_url": "http://localhost"}' | jq

    TODO

    • [x] Show on the pr page if a pr was scheduled for auto merge
      • [x] Add a comment {User} scheduled this pr to auto-merge
    • [x] Provide an option to bypass auto merge entirely and merge directly without waiting for status checks
    • [x] Provide an option to cancel auto merge once it's set
    • [x] Add a check to see if all checks already succeeded in routers/repo/pull.go:676 to prevent scheduling a pr for merging after all checks already passed.
    • [x] Only check if all required status checks succeeded or all if none are required in services/automerge/pull_auto_merge.go:89
    • [x] Add an event comment to the pr timeline if it was set/unset to auto merge
    • [x] Make sure to check all prs with the same head branch of a commit for merging PRs when a check succeeds
    • [x] Fix dropdown button width of the merge button
    • [x] Allow both directly merging and scheduling for merge
    • [x] Add "merge now" button next to "merge when checks succeed"
    • [x] Cleanup scheduled pr merge when it failed to get merged + log error
    • [x] Move handling to [a queue](example: https://github.com/go-gitea/gitea/pull/19390)
    • [x] Check permissions again right before merging
    • [x] Automerge does not respect other branch protections yet
    • [x] ~~pull_service.Merge() need a lock~~ -> move it into won pull (#19520)
    • [ ] ~~Fix UI glitch to Create AutoMerge~~ -> new issue ... new pull #19621
    • [x] API cancel auto-merge

    Optional TODOs

    • [ ] Show auto merge status on PR list

    close #3905

    kind/feature lgtm/done kind/api 
    opened by kolaente 111
  • OAuth2 auto-register

    OAuth2 auto-register

    Changes

    • Refactored user creation (code deduplication, see individual commit messages: a3366c4 and 6e2ece4)
    • Added auto-registration for OAuth2 users

    Settings

    A new settings section (oauth2_client) is added and documented in custom/conf/app.ini.sample and content/doc/advanced/config-cheat-sheet.en-us.md.

    Breaking changes?

    No. The default settings reflect the current behaviour. And OAuth2 auto-register needs to be manually enabled.

    Referenced Issues

    Implements #3520 und solves the secondary consideration in #1036.

    kind/feature lgtm/done changelog reviewed/confirmed 
    opened by mgjm 110
  • Added dependencies for issues (#2196)

    Added dependencies for issues (#2196)

    Introduction

    This PR implements dependencies for issues, as described in #2196.

    It lets you define anonther issue as a dependency for an issue. You the cannot close the issue if it has any dependent issues which aren't closed. If you try to autoclose an issue via commit message which still has dependencies left, autoclose will simply not close the issue, but the commit will not fail.

    You can disable dependencies in the repo settings.

    Example: You set #2, #3 and #4 as a dependency of #1. Now you need to close all #2, #3 and #4, before you can close #1.

    Screenshots

    Overview of Issue Dependencies (sidebar): Overview of Issue Dependencies (sidebar):

    Comments after adding a new dependency: Comments after adding a new dependency

    Questions

    Currently, i would describe this as "working, but not finished", as there are some questions i have:

    1. For now, you need the issue ID (not the index) to create a dependency. This is not very user-friendly, I'd like to have some kind of search bar where you search for the issue title/index select it, and it'll do the rest. Problem: There is no API-Endpoint to search for issues like that (Or just returns a list of all issues as JSON). I think this should be implemented first. If such thing already exists, please point me to it, I haven't found any.
    2. It is currently possible to create dependencies with issues from other repositories. Is this okay? Or should one not be able to do this, as it could create a massive overhead with all permission-checking etc.
    3. There is some work to be done with migrations etc, currently i simply put the xorm-call at the beginning of the function, which probably shouldn't be there. Where is the appropriate place to put this?

    This is my first time I've done something like this in Go, before i've only played around with Go but never really did anything bigger. So, there are probably some things I didn't got right as a novice. Looking forward to hear your improvents to be made! Also thanks to @JonasFranzDEV who has helped me a lot.

    kind/feature lgtm/done changelog 
    opened by kolaente 103
  • Screenreaders unable to read Gitea's various dropdowns

    Screenreaders unable to read Gitea's various dropdowns

    • Gitea version (or commit ref): 1.8.1

    • Git version: 2.21.0

    • Operating system: windows10-1903

    • Database (use [x]):

      • [ ] PostgreSQL
      • [x] MySQL
      • [ ] MSSQL
      • [x] SQLite
    • Can you reproduce the bug at https://try.gitea.io:

      • [ ] Yes (provide example URL)
      • [ ] No
      • [x] Not relevant
    • Log gist: not needed

    Description

    Gitea, as with gogs which it was forked from, has many accessibility issues with screen readers including:

    1. The dropdown menus are clickables, so many screen readers do not know what to do with them as they do not use the mouse cursor.
    2. The license selection/.gitignore selection (and most other menus of that type) are inaccessible, as they all use mouse oriented actions.
    3. Possibly others I haven't seen yet.

    Unfortunately, this is caused by the toolkit you use, which does not seem interested in making their toolkit accessible. It can be worked around with aria markup, or by changing toolkits (the first of which is easier to begin with but requires more maintenance over time, the second of which is of course much harder, but once you get it done it's done pretty much forever).

    See the original issue on gogs for more info: gogs/gogs#3340

    Looking forward to seeing if anything can be done about this. -dingpengyu. tests screen reader: NVDA thank

    kind/proposal 
    opened by xingkong013 91
  • Slow repository browsing in 1.14.x

    Slow repository browsing in 1.14.x

    • Gitea version (or commit ref): 1.14.x
    • Git version: 2.31.1
    • Operating system: FreeBSD 13
    • Gitea built using ports collection (www/gitea)
    • Gitea started by startup script provided by www/gitea port
    • Database (use [x]):
      • [x] PostgreSQL 12.6
      • [ ] MySQL
      • [ ] MSSQL
      • [ ] SQLite
    • Can you reproduce the bug at https://try.gitea.io:
      • [x] Yes (https://try.gitea.io/tsowa/FreeBSD_ports)
      • [ ] No
    • Log gist: https://www.ttmath.org/gitea.log

    Description

    I saw a similar thread but there is "windows" in the title so I create a new issue. Gitea 1.14.x is much slower in repository browsing than Gitea 1.13.

    Sample repo running with 1.14.1: https://gitea.ttmath.org/FreeBSD/ports Try to open any directory, for example: https://gitea.ttmath.org/FreeBSD/ports/src/branch/main/audio It takes between 50-150 seconds to open a page.

    The same repo running with 1.13.7: https://giteaold.ttmath.org/FreeBSD/ports Try to open similar directory, for example: https://giteaold.ttmath.org/FreeBSD/ports/src/branch/main/audio I takes about 5 seconds.

    You can see the same problem on try.gitea.io: https://try.gitea.io/tsowa/FreeBSD_ports But you have a cache so you have to find a directory which was not open before. Opening such a page takes 100-300 seconds.

    Let me know if more info is needed.

    performance/speed performance/bigrepo 
    opened by tsowa 87
  • Pastebin service

    Pastebin service

    • Gitea version (or commit ref): all
    • Git version: all
    • Operating system: all
    • Database (use [x]):
      • [x] PostgreSQL
      • [x] MySQL
      • [x] SQLite
    • Can you reproduce the bug at https://try.gitea.io:
      • [x] Yes (provide example URL)
      • [ ] No
      • [x] Not relevant

    Description

    I am used to Gist, the pastebin service, since it offers me the option to collect all my pasted code in one central place and that in the same interface, text editor and so on, which i use on Github, so all is very consistent.

    I suggest to implement such a service for Gitea too, as Gitlab does it with their snippets.

    This is something we all use, it provides users and developers the very same look and feel as in Gitea, is easy to implement (so far i as a newbie can see) and offer us a history of all the already posted code.


    Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

    kind/proposal 
    opened by ShalokShalom 86
  • Pushing to empty repository is not reflected in web UI

    Pushing to empty repository is not reflected in web UI

    • Gitea version (or commit ref): 1.10.2
    • Git version: 2.25.0
    • Operating system: ArchLinuxARM
    • Database (use [x]):
      • [ ] PostgreSQL
      • [ ] MySQL
      • [ ] MSSQL
      • [x] SQLite
    • Can you reproduce the bug at https://try.gitea.io:
      • [ ] Yes (provide example URL)
      • [x] No: https://try.gitea.io/mxt92822/empty_test
      • [ ] Not relevant
    • Log gist: https://gist.github.com/kauron/136587e6abf7611481d7461000eb8c4d

    Description

    Exactly the same as in #9365, but the filesystem is mounted with exec. I think the localhost API calls are the hooks, but I'm not sure. The hooks in the repo run properly when executed manually through the terminal.

    (description copied from the previously mentioned issue)

    I created a new repo and pushed a local repository. I tried it both with --all (it has two branches) and without (pushed only master). Either way the repository is not changed to non-empty. I did it manually in the DB to set the is_empty column to 0 which fixed the problem.

    opened by kauron 84
  • Voting for new logo

    Voting for new logo

    @qdbdbp @kolaente Let's vote for Gitea's new Logo. First reply is for @kolaente and the second is for @qdbdbp and other replies before that will be deleted. The vote duration is from now until v1.2 release (about 10 days) I think or we have to put this to v1.3.

    kind/proposal 
    opened by lunny 82
  •  Wrong suggested changes url in dashboard

    Wrong suggested changes url in dashboard

    Description

    Can be reproduce in https://try.gitea.io/

    See Screenshot below. Language must select Chinese, no problem with English version.

    Gitea Version

    1.17.0+dev-573-ge45738e3c

    Can you reproduce the bug on the Gitea demo site?

    Yes

    Log Gist

    No response

    Screenshots

    image

    Git Version

    No response

    Operating System

    No response

    How are you running Gitea?

    no need.

    Database

    No response

    kind/bug 
    opened by NepPure 0
  • Use a better OlderThan for DeleteInactiveUsers

    Use a better OlderThan for DeleteInactiveUsers

    • Currently the OlderThan is zero, for instances that enable or run this task this could actually delete just new created users that still need to confirm their email.
    • This patch fixes that by setting the default OlderThan to the ActiveCodeLives setting, which corresponds to the amount of time that a user can active their account via email and thus avoiding the issue of deleting 'legit' unactivated users.
    kind/enhancement lgtm/need 1 
    opened by Gusted 1
  • Sort by popularity, allow upvotes and downvotes

    Sort by popularity, allow upvotes and downvotes

    Feature Description

    I am surprised that this issue was not already filled. Tried to find it and failed, sorry if is a duplicate.

    This is a feature request to port gitlab feature into gitea. That whould allow identifyying issues that are in high demand. Also, some kind of voting to understand priority, consensus; and avoid using yet another platform because of this.

    https://docs.gitlab.com/ee/user/project/issues/sorting_issue_lists.html#sorting-by-popularity

    so in any issue, you can react with thumbs up and thumbs down [screenshot1]; also with other reactions; but let's stick that part out of scope for this issue (I saw other issues talking about reactions #14124, #16676, and sure that etc)

    as an example, let me link to the most popular issue from gitlab https://gitlab.com/gitlab-org/gitlab/-/issues/17800

    here you have the whole list to test the different sortings, or the one about popularity https://gitlab.com/gitlab-org/gitlab/-/issues , or see [screenshot2]

    https://docs.gitlab.com/ee/user/project/issues/sorting_issue_lists.html#sorting-by-popularity

    Screenshots

    [screenshot1]

    image

    [screenshot2]

    image

    kind/proposal kind/feature 
    opened by pedro-nonfree 0
  • Telegram hook on the release sends a link to the tag, not to the release

    Telegram hook on the release sends a link to the tag, not to the release

    Description

    When creating a release in repo, the telegram bot sends the following message:

    [{owner}/{repo}] Release created: {release_title} by {publisher}
    

    A link is added to {release_title} : https://{base_url}/{owner}/{repo}/src/{tag_name} This is a link to the tag although a link to the release was expected: https://{base_url}/{owner}/{repo}/releases/tag/{tag_name}

    Gitea Version

    1.16.5

    Can you reproduce the bug on the Gitea demo site?

    No

    Log Gist

    No response

    Screenshots

    No response

    Git Version

    No response

    Operating System

    Windows 10

    How are you running Gitea?

    APP_NAME = <hidden>
    RUN_USER = <hidden>
    RUN_MODE = prod
    
    [database]
    DB_TYPE  = postgres
    HOST     = <hidden>
    NAME     = <hidden>
    USER     = <hidden>
    PASSWD   = <hidden>
    SCHEMA   = 
    SSL_MODE = <hidden>
    CHARSET  = <hidden>
    PATH     = <hidden>
    LOG_SQL  = false
    
    [repository]
    ROOT = <hidden>
    DEFAULT_PRIVATE = private
    DEFAULT_BRANCH = master
    
    [server]
    SSH_DOMAIN       = <hidden>
    DOMAIN           = <hidden>
    ROOT_URL         = <hidden>
    HTTP_PORT        = <hidden>
    DISABLE_SSH      = false
    SSH_PORT         = 22
    LFS_START_SERVER = true
    LFS_CONTENT_PATH = <hidden>
    LFS_JWT_SECRET   = <hidden>
    OFFLINE_MODE     = false
    LANDING_PAGE = login
    LFS_MAX_FILE_SIZE = 2147483648
    
    [lfs]
    STORAGE_TYPE = local
    PATH = <hidden>
    
    [ui]
    ISSUE_PAGING_NUM = 30
    
    [attachment]
    PATH = <hidden>
    MAX_SIZE = 2048
    MAX_FILES = 6
    
    [mailer]
    ENABLED = false
    
    [service]
    REGISTER_EMAIL_CONFIRM            = false
    ENABLE_NOTIFY_MAIL                = false
    DISABLE_REGISTRATION              = true
    ALLOW_ONLY_EXTERNAL_REGISTRATION  = false
    ENABLE_CAPTCHA                    = false
    REQUIRE_SIGNIN_VIEW               = true
    DEFAULT_KEEP_EMAIL_PRIVATE        = false
    DEFAULT_ALLOW_CREATE_ORGANIZATION = false
    DEFAULT_ENABLE_TIMETRACKING       = true
    NO_REPLY_ADDRESS                  = noreply.localhost
    DEFAULT_USER_VISIBILITY = private
    
    [picture]
    DISABLE_GRAVATAR        = false
    ENABLE_FEDERATED_AVATAR = true
    
    [openid]
    ENABLE_OPENID_SIGNIN = false
    ENABLE_OPENID_SIGNUP = false
    
    [session]
    PROVIDER = file
    
    [log]
    MODE      = console
    LEVEL = INFO
    ROOT_PATH = <hidden>
    ROUTER    = console
    STACKTRACE_LEVEL = Error
    
    [git.timeout]
    DEFAULT = 18000
    MIGRATE = 86400
    MIRROR  = 7200
    CLONE   = 18000
    PULL    = 18000
    GC      = 30
    
    [security]
    INSTALL_LOCK       = true
    INTERNAL_TOKEN     = <hidden>
    PASSWORD_HASH_ALGO = <hidden>
    

    Database

    PostgreSQL

    kind/bug good first issue 
    opened by sergey-cs 0
  • gitea dump add quiet option

    gitea dump add quiet option

    Feature Description

    It would be nice if we can have a quiet option to gitea dump, this would be useful for cron combined with -f-.

    I can use 2>/dev/null but in case of error then I won't see it anymore,

    Screenshots

    image kind/proposal kind/feature 
    opened by chmouel 0
Releases(v1.16.7)
Owner
Gitea
Git with a cup of tea
Gitea
A reverse engineered github actions compatible self-hosted runner using nektos/act to execute your workflow steps

github-act-runner A reverse engineered github actions compatible self-hosted runner using nektos/act to execute your workflow steps. Unlike the offici

null 80 May 2, 2022
Kubernetes operator for the Azure DevOps self-hosted pipe-line agent.

Kubernetes operator for the Azure DevOps self-hosted pipe-line agent. The operator adds an extra layer of configuration on top of the default images like: proxy settings, pool settings and auth keys.

Bart 1 Jan 11, 2022
Manages nodes in hybrid k8s self-hosted cluster

node-manager Manages nodes in hybrid k8s self-hosted cluster Supported providers Contabo Hetzner Robot (dedicated) Supported commands Heal - reboots a

webtor.io 0 Dec 23, 2021
Self-hosted uptime monitor

minute Self-hosted uptime monitor. Usage $ go build $ ./minute sites.txt Configuration Configuration is done through the sites.txt file. <SMTP server

Theodore Keloglou 2 May 2, 2022
Developer Self-Service Across Clusters

Monoskope (m8) Monoskope (short m8 spelled "mate") implements the management and operation of tenants, users and their roles in a Kubernetes multi-clu

finleap connect 6 Mar 9, 2022
A tiny self-contained pasting service with a built-in database.

A tiny self-contained pasting service with a built-in database.

SWZ 2 Dec 18, 2021
Watchtower for Git: automatically keep local Git repositories up to date with their remotes

CrowsNest Watchtower for Git: automatically keep local Git repositories up to date with their remotes. Configuration Flags --run-once or -r: Normally

Simon 60 Apr 25, 2022
Enable your Go applications to self update

go-selfupdate Enable your Golang applications to self update. Inspired by Chrome based on Heroku's hk. Features Tested on Mac, Linux, Arm, and Windows

Mark 979 May 16, 2022
Hermit manages isolated, self-bootstrapping sets of tools in software projects.

Hermit - uniform tooling for Linux and Mac Hermit installs tools for software projects in self-contained, isolated sets, so your team, your contributo

Cash App 312 May 9, 2022
self-made curl because windows doesn't have one 😡

Go-Curl Basic Feature of Curl made on go Installation go mod tidy then go build . Usage go-curl get "https://jsonplaceholder.typicode.com/posts/1" -b=

Akbar H. P. S. 0 Dec 12, 2021
Linux provisioning scripts + application deployment tools. Suitable for self-hosting and hobby-scale application deployments.

Apollo Linux provisioning scripts + application deployment tools. Suitable for self-hosting and hobby-scale application deployments. Philosophy Linux-

K T Corp. 1 Feb 7, 2022
Open Service Mesh (OSM) is a lightweight, extensible, cloud native service mesh that allows users to uniformly manage, secure, and get out-of-the-box observability features for highly dynamic microservice environments.

Open Service Mesh (OSM) Open Service Mesh (OSM) is a lightweight, extensible, Cloud Native service mesh that allows users to uniformly manage, secure,

Open Service Mesh 2.4k May 15, 2022
Cheiron is a Kubernetes Operator made with OperatorSDK for reconciling service account and attaching imagePullSecrets to service accounts automatically

anny-co/cheiron NOTE: Cheiron is currently in very early stages of development and and far from anything usable. Feel free to contribute if you want t

anny 2 Sep 13, 2021
crud is a cobra based CLI utility which helps in scaffolding a simple go based micro-service along with build scripts, api documentation, micro-service documentation and k8s deployment manifests

crud crud is a CLI utility which helps in scaffolding a simple go based micro-service along with build scripts, api documentation, micro-service docum

Piyush Jajoo 0 Nov 29, 2021
Easy-to-use CUI for fixing git conflicts

Easy-to-use CUI for fixing git conflicts I never really liked any of the mergetools out there so I made a program that is somewhat easier to use. ?? I

Mike JS. Choi 1.8k May 13, 2022
A Simple and Comprehensive Vulnerability Scanner for Container Images, Git Repositories and Filesystems. Suitable for CI

A Simple and Comprehensive Vulnerability Scanner for Containers and other Artifacts, Suitable for CI. Table of Contents Abstract Features Installation

Aqua Security 11.8k May 15, 2022
Create changelogs for Helm Charts, based on git history

helm-changelog Create changelogs for Helm Charts, based on git history. The application depends on the assumption that the helm chart is released on t

Frederik Mogensen 33 Apr 16, 2022
Semantic version generator using git commit keywords and overrides

Semantic version generator Project created overnight, to prove that management of semantic versioning is NOT painful and do not require arguments and

Lukasz Raczylo 25 May 4, 2022