Make Packit easier to contribute

[lachmanfrantisek]

People have a tough time to contribute to Packit, mainly the service part. Let's collect tasks to improve the situation. (Anyone's suggestions are welcome.)

[FrostyX]

We have the same problem in Copr. Fairly easy to contribute to copr-cli and python-copr but more complicated for the server side. This is the best I could come up with - https://frostyx.cz/posts/copr-docker-compose-without-supervisord

@praiskup also recently created "single host setup" via Ansible playbooks
fedora-copr/copr#3967
but I am not sure if it will be helpful for new contributors or rather only people who want to deploy their own instance.

I am curious to see what you come up with in this epic, and whether it could be applicable for Copr too.

[Jany26]

Since I am new to many tools used in Packit and to Packit codebase itself, more detailed description (especially the order of some steps) in CONTRIBUTING.md about how to setup the packit-service locally would be much appreciated. It also seems that some comments are outdated (stuff that links to code, like here). Maybe even a script could be created that populates the secrets folder such that "something" working can be run and played with.

[betulependule]

I have a couple of notes:

1. I see that the contributing guidelines contain some passages (like in Running packit-service locally) which require you to have access to secrets (which only the Packit team should have access to). I thought anyone outside the team should be able to contribute, yet the guidelines don't seem to reflect that. The current guidelines as they are currently written in the CONTRIBUTING.md file don't feel very newcomer-friendly because of this. I feel like there should be a clear distinction between what is relevant to community contributors and the team.

2. How often do we even use Building images locally and Running packit-service locally?

3. Outside of the guidelines themselves, what I most struggled with personally is that the code of packit-service is quite complex with a lot of technologies being used (Redis queue, Celery, Sentry etc.) and there is no proper documentation regarding the code besides docstrings (as far as I know), and I had to ask for explanations among team members. Wouldn't at least some high-level documentation be beneficial? Something to give an overview of what the events, service and worker folders, the celerizer.py, models.py and other files contain and how they relate? What I've personally had the most trouble with was following the data flow (for example how the data is processed when a Github event happens, how SteveJobs processes it and how it, along with all necessary metadata, eventually gets to an appropriate handler). Perhaps even packit and ogr would benefit from having at least some brief high-level overview documentation.

4. Side note: Are we sure CONTRIBUTING.md is up to date? It hasn't been updated in two years. The again, there maybe isn't all that much that would need to be updated regularly.

[nforro]

1. I see that the contributing guidelines contain some passages (like in Running packit-service locally) which require you to have access to secrets (which only the Packit team should have access to). I thought anyone outside the team should be able to contribute, yet the guidelines don't seem to reflect that.

That's not true, the instructions state:

You also need to populate secrets/packit/dev/ manually, for instructions see deployment repo.

Where you can read:

Either:

• generate them with make generate-local-secrets or
• if you're a Packit team member with access to Bitwarden vault, download stg/ secrets (DEPLOYMENT=stg make download-secrets) and copy into dev/

How usable the generated secrets are, that's another question. And perhaps something to improve.

---

2. How often do we even use Building images locally and Running packit-service locally?

All the time? 😅 How else would you want to do non-trivial changes to the service?

---

3. Outside of the guidelines themselves, what I most struggled with personally is that the code of packit-service is quite complex with a lot of technologies being used (Redis queue, Celery, Sentry etc.) and there is no proper documentation regarding the code besides docstrings (as far as I know)

That's a good point, and I remember struggling with this as well, notably Celery and how the task distribution/processing works. That could be documented/explained better.

3. What I've personally had the most trouble with was following the data flow (for example how the data is processed when a Github event happens, how SteveJobs processes it and how it, along with all necessary metadata, eventually gets to an appropriate handler).

Also a good point, though I feel the source code is quite self-explanatory and doesn't take that long to grasp. That doesn't mean more documentation or some high level overview wouldn't help.

[jpodivin]

I have been trying to address some issues of the development process. Broken test cases and outdated database schema had the most impact. But I agree that the documentation could use a touch up.

That being said. I'm more worried about what we are not testing. As noted above, the code is very complex and things can slip. It is entirely possible that existing tests no longer reflect the state of the code.

Besides that, there is a substantial number of TODOs in the code. And that is a major opportunity. Some of them could serve as nice introductory tasks, if properly described.

[betulependule]

It might also be nice to have a troubleshooting section in CONTRIBUTING.md.