-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Get rid of GitHub, use gitea #60
Comments
I disagree. GitHub is widely used and known whereas Gitea is not. It also bloats the installation which is a real issue as we are resource constrained for this tutorial. Using GitHub.com shows how to use Keptn is a real world scenario whereas Gitea feels too "demo-mode" and would lead to lots of "well Keptn works with this thing called Gitea but does it work with [GitHub | Gitlab ... etc. ]" questions in Slack. In my experience with Keptn users, the issue isn't using GitHub, it's the fact that Keptn mandates an empty repo - meaning a brand new repo for every test project. I'd rather see the development time, tutorial maintenance effort and issue handling go towards progressing Keptn's folder based structure (which AFAIK will allow non-empty folder usage). Rather than yet-another-dependency on a niche tool like Gitea. Overall I just don't see the net benefit (in this particular case for using Gitea over GitHub). Perhaps the creation and use of a GitHub.com provisioner is the solution here? This is just my opinion though so I'll wait for others to chime in. |
Hi Adam, I'm absolutely on your side regarding being resource constraint. Though I need to heavily disagree with the Gitea vs. GitHub part. Depending on what tools you use, you could make a similar comparision about GitHub vs. BitBucket or Azure DevOps or GitLab. The main feature that you want to demonstrate with Keptn is that it stores project-related files in Git (not GitHub), and that the user has full control over all files. In fact, we can even let the user access Gitea and take a look themselves. Last but not least, and I can confirm this from many people I have spoken too: Having to create a token on GitHub (as well as a repo) is way too much for a demo/tutorial.
Would love to see this, also for other providers, and then the user can choose. |
I'm looking into this now. Existing (GitHub based) tutorial is 81% full on disk at the
Gitea took over 3 minutes to startup:
Update. I don't think this is realistic as it would mean adding another 3 minutes to the demo startup time. You've convinced me that a self-contained demo with no GitHub dependency is a good thing, but we need to look for a different solution until Gitea starts quicker. Due to this issue, Keptn takes about 3mins to startup so Keptn + Gitea would be 6 minutes (or 10% of the users total time on environment). Postgresql
MariaDBSlightly quicker (with memcached disabled) at 2min50s MySQLSlower at almost 4mins |
Just note that benchmarking a single run is not very representative, especially if you compare MariaDB, MySQL and PostgreSQL. There are many variables, especially on shared infrastructure. But I agree in general that this adds more time to the initial startup time, and that because of resource limitations, it's currently not possible. Thanks anyway for trying it out! |
I'm going to tentatively put this back on the table because Killercoda have just increased their disk sizes. Will re-investigate. |
With the introduction of resource-service in Keptn 0.16 the git upstream became mandatory, which is why GitHub is mandatory for this tutorial.
IMO this just adds an extra step that's confusing for new users, and this is why we published the keptn-gitea-provisioner-service.
In order to use it with Keptn 0.17, the following things have to be done:
We have information available on how this works here: https://github.com/keptn-sandbox/keptn-gitea-provisioner-service#quickstart
Acceptance Criteria
gh
CLI is no longer installedadd approval step
refactored such that it works with just the git repo (probably just needsgit
commands)setup keptn step
no longer needs to create a repo - that's handled by the provisionerThe text was updated successfully, but these errors were encountered: