Figure out a nice way for relman to do CI in community cluster and deploy hooks into firefox-ci
Categories
(Taskcluster :: Operations and Service Requests, enhancement)
Tracking
(Not tracked)
People
(Reporter: bstack, Unassigned)
References
Details
We're not going to get this working particularly nicely before the tcw on the 9th but we can use this bug to discuss what a nice medium/long-term solution is here.
Some suggestions I've seen are to have it automatically make phabricator PRs. Please feel free to brainstorm in here!
|
||
Comment 1•6 years ago
|
||
Another option is what we're leaning toward in community-ci: "carve out" specific resources that are not managed by ci-configuration, and let the automation for code-coverage etc. manage those resources directly. This cedes a little bit of control, but that may be OK especially if it only allows management of the hooks and not the roles associated with those hooks.
|
||
Comment 2•6 years ago
|
||
That would work for us, we only need to update regularly the docker image reference in the hook definition.
If we need to add more hooks or scopes to existing hooks, i am totally fine with making a patch on Phabricator.
|
||
Comment 3•6 years ago
|
||
Tom, what do you think of allowing Bastien to land docker-image updates himself, and giving scopes to allow him to deploy this (with a --grep so he doesn't even attempt altering other things)
I don't mind doing this ourselves, but probably useful to get out of the way on this work, I think.
|
||
Comment 4•6 years ago
|
||
Jordan, what do you think if we (me and Bastien) had rights to review, land and apply these kind of patches?
https://hg.mozilla.org/ci/ci-configuration/rev/df185e33107faff652e64dbfc8def30a1def2d27
|
||
Comment 5•6 years ago
|
||
(In reply to Marco Castelluccio [:marco] from comment #4)
Jordan, what do you think if we (me and Bastien) had rights to review, land and apply these kind of patches?
https://hg.mozilla.org/ci/ci-configuration/rev/df185e33107faff652e64dbfc8def30a1def2d27
I think this makes sense if the scopes required limit what else can be reviewed and deployed.
If I recall, Mihai and Tom were discussing this this week. One idea was to be able to facilitate a way for you to push, review, and stage a commit for deployment but releng would do the actual deploying. So reduce the steps on your side but have it still gated.
Tom and Mihai have a better idea of this or may suggest something entirely different. I would like to reduce the friction here and make this easier for both sides. We will be looking for ways in H1 to make administering smoother and more timely and this request falls into that category.
|
|
||
Comment 6•6 years ago
|
||
On a side note, I just want to give kudos to Mihai and Johan who apply our regular updates on the testing & production hooks as they are on the same timezone as Marco and myself. They are almost as fast as an automated system !
|
||
Comment 7•6 years ago
|
||
I think the best way to handle this is to move the (or at least some of the) CI for these projects into the firefox-ci cluster. If the images are built in firefox-ci tasks, then the hooks can point at those indexed images, rather than needing to update the pinned images all the time. This would require switching to using docker-in-docker to build the images, as we don't have privileged docker-workers in the firefox-ci cluster, but I think that should be possible.
|
||
Comment 8•6 years ago
|
||
(In reply to Tom Prince [:tomprince] from comment #7)
I think the best way to handle this is to move the (or at least some of the) CI for these projects into the firefox-ci cluster. If the images are built in firefox-ci tasks, then the hooks can point at those indexed images, rather than needing to update the pinned images all the time. This would require switching to using docker-in-docker to build the images, as we don't have privileged docker-workers in the firefox-ci cluster, but I think that should be possible.
Piggy-backing on Tom's idea which I think could save both sides a lot of time.
|
|
||
Comment 9•6 years ago
|
||
(In reply to Tom Prince [:tomprince] from comment #7)
If the images are built in firefox-ci tasks, then the hooks can point at those indexed images, rather than needing to update the pinned images all the time. This would require switching to using docker-in-docker to build the images
So Bastien, Marco, if you can do this (we can consult), the releng piece will be ~1 day of work and I think you will be in a better, more self serve position.
|
|
||
Comment 10•6 years ago
|
||
All right, i'm already looking into this here to build our images with dind.
|
|
||
Comment 11•6 years ago
|
||
The code review project now uses docker-in-docker to build the images, we don't need the privileged workers anymore.
What would be the next steps to build these images on firefox-ci ? Ideally we would only move the bot image build on firefox-ci, as that's the only one requiring to run on firefox-ci.
Once this process goes well for code-review, i'll switch code-coverage & bugzilla-dashboard-backend
|
|
||
Comment 12•6 years ago
|
||
Any update on that ? It may have been forgotten with the All Hands ...
|
|
||
Comment 13•6 years ago
|
||
I chatted with :bastien about this today, and he is going to drive the ci-config changes needed to get this working.
|
|
||
Comment 14•5 years ago
|
||
The code review bot now uses Docker images built & indexed on Firefox-CI, we don't need to bump the Docker image hash in ci-configuration anymore.
We just need to do the same process for code-coverage now (it should be faster, as we can re-use the code-analysis worker pool)
|
|
||
Comment 15•5 years ago
|
||
mozilla/code-coverage now builds & uses indexed images on firefox-ci, we do not need releng's review on image bumps. Thanks guys !
Description
•