Open christian-kreuzberger-dtx opened 2 years ago
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.
Perhaps the creation and use of a GitHub.com provisioner is the solution here?
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 Installation complete
message.
$ df -H
Filesystem Size Used Avail Use% Mounted on
udev 1.1G 0 1.1G 0% /dev
tmpfs 209M 1.3M 208M 1% /run
/dev/vda1 11G 8.3G 2.0G 81% /
tmpfs 1.1G 0 1.1G 0% /dev/shm
tmpfs 5.3M 0 5.3M 0% /run/lock
tmpfs 1.1G 0 1.1G 0% /sys/fs/cgroup
/dev/loop0 65M 65M 0 100% /snap/core20/1081
/dev/loop1 71M 71M 0 100% /snap/lxd/21545
/dev/loop2 34M 34M 0 100% /snap/snapd/13170
/dev/vda15 110M 5.5M 104M 5% /boot/efi
/dev/loop3 47M 47M 0 100% /snap/snapd/15534
/dev/loop4 66M 66M 0 100% /snap/core20/1434
/dev/loop5 72M 72M 0 100% /snap/lxd/22753
overlay 11G 8.3G 2.0G 81% /var/lib/docker/overlay2/c007442bad14c9986fc517c3613f6858eaa1bfb795dc37a9c755c949f0a23bda/merged
overlay 11G 8.3G 2.0G 81% /var/lib/docker/overlay2/9344c51e8577cdc952fb2bfb9994fcdc31e2e9cf4660e15893955278c1633768/merged
Gitea took over 3 minutes to startup:
$ kubectl -n gitea get pods
NAME READY STATUS RESTARTS AGE
svclb-gitea-http-46hg2 1/1 Running 0 3m23s
gitea-memcached-7b44bc5f74-rthkk 1/1 Running 0 3m23s
gitea-postgresql-0 1/1 Running 0 3m23s
gitea-0 1/1 Running 0 3m23s
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).
Every 2.0s: kubectl -n gitea get pods ubuntu: Sun Jul 31 21:48:59 2022
NAME READY STATUS RESTARTS AGE
svclb-gitea-http-p8n9b 1/1 Running 0 2m7s
gitea-memcached-7b44bc5f74-ql9fl 1/1 Running 0 2m7s
gitea-0 0/1 Init:2/3 0 2m8s
gitea-postgresql-0 1/1 Running 0 2m8s
Every 2.0s: kubectl -n gitea get pods ubuntu: Sun Jul 31 21:50:07 2022
NAME READY STATUS RESTARTS AGE
svclb-gitea-http-p8n9b 1/1 Running 0 3m16s
gitea-memcached-7b44bc5f74-ql9fl 1/1 Running 0 3m16s
gitea-postgresql-0 1/1 Running 0 3m17s
gitea-0 0/1 Running 0 3m17s
Slightly quicker (with memcached disabled) at 2min50s
Slower 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 provisioner