Research decoupling of Fedora CI#224
Conversation
f25be2d to
be6ec24
Compare
be6ec24 to
b54cbf8
Compare
| - importing the code from new repo | ||
|
|
||
| - cleaner transition | ||
| - requires more initial effort and might be more complex to set up |
There was a problem hiding this comment.
I would vote for this approach, it's certainly more work at the start but I think it will pay off.
There was a problem hiding this comment.
I am not sure I follow this. It means that packit-service will import some code from fedora-ci? If it is, I don't think this is what we want in the long run? I can see, on the other hand, a third repo from where both fedora-ci and packit-service import code. At the beginning it could be a very large base and then it should became smaller, probably.
There was a problem hiding this comment.
IIUC it means packit-service will import code from fedora-ci during the transition period (until a new deployment runs the fedora-ci code directly).
| ``` | ||
|
|
||
| - code migration: | ||
| - identify and move all Fedora CI-related worker functionality from packit-service to the new repository; this concerns jobs that do not depend on a repo having Packit configuration in the repository |
There was a problem hiding this comment.
I am wondering if there would be some code (I am thinking to the events as an example) that has to be moved in a third repository shared both by packit-service and fedora-ci?
There was a problem hiding this comment.
following how we did this in hardly, I would start with having the service code in one repository (i.e. all the events being placed in packit-service), as decoupling of that could be more complex.
There was a problem hiding this comment.
I am probably missing something here: if events will stay in packit-service, and packit-service will import from fedora-ci but fedora-ci would need events in packit-service... I don't think we can make this work?
There was a problem hiding this comment.
and packit-service will import from fedora-ci
do you mean this just for the "importing" solution for the transition period? That might be a good point. Regarding the transition, I am more inclined to trying minimise the time of transition and the code changes rather.
There was a problem hiding this comment.
yes, I am referring the transition time solution. I am not against a quick solution, I just fear we may hit cyclic imports and not being able to solve them quickly.
There was a problem hiding this comment.
@majamassarini yes I see your point now and I agree. And it might still not even really be "quick" nevertheless. Let's discuss more tomorrow.
| # To discuss | ||
|
|
||
| - repo naming | ||
| - fedora-ci |
b54cbf8 to
fbe6f8e
Compare
|
|
||
| ## Code | ||
|
|
||
| - create the new repo (`https://github.com/packit/fedora-ci`?) structure, something like this: |
There was a problem hiding this comment.
I'd probably prefer more explicit, something like fedora-ci-worker
| - code migration: | ||
| - identify and move all Fedora CI-related worker functionality from packit-service to the new repository; this concerns jobs that do not depend on a repo having Packit configuration in the repository | ||
| - set up tests and CI | ||
| - create files needed for deployment: `run_worker.sh`, Containerfile, docker-compose file, etc. |
There was a problem hiding this comment.
Note
Time to move on to podman-compose, I hate the complaints in shell each time I forget to pass COMPOSE
| ## Identity | ||
|
|
||
| - we probably want a new identity (or 2, both for stg and prod) on `src.fedoraproject.org` to be set up | ||
| - current Fedora CI user (`releng-bot`) is in these groups: |
fbe6f8e to
1d11f3f
Compare
1d11f3f to
336a23a
Compare
for more information, see https://pre-commit.ci
Co-authored-by: Matej Focko <mfocko@users.noreply.github.com>
for more information, see https://pre-commit.ci
Fixes packit/packit-service#2737