Closed gruberb closed 2 weeks ago
Is it fine that this will not have a path to working (other than porting to taskcluster) once we are in m-c?
Is it fine that this will not have a path to working (other than porting to taskcluster) once we are in m-c?
Yes. I think we can even re-use the dumps
once we are in m-c
and delete "ours". But I thought it was 1h of work and not wasted effort. Fine to delete this once we are in m-c
and rethink.
Is it fine that this will not have a path to working (other than porting to taskcluster) once we are in m-c?
Yes. I think we can even re-use the
dumps
once we are inm-c
and delete "ours".
I think this is the key question, the actual script is pretty simple. AFAICT, Bastian's plan will work. Once we're in m-c, we can drop the updating script and use their dump data.
We want to keep the in-tree remote-settings dumps up to date. For this, a GitHub Actions workflow seems to be the easiest way for now. The workflow will check once a week if there is new data (through the
cargo remote-settings dump-sync
command). And commit any changes to a new branch and open a PR against main.