define new destination for charts backups operation

[johndietz]

John:

• if we were to update the registry destination to our new permanent chartmuseum in mgmt-24 on the konstruct.io domain, could we:
  update this line https://github.com/konstructio/charts-mirror/blob/main/.github/workflows/mirror-charts.yaml#L11 to the new charts.konstruct.io instance
  dispatch the job and have all the charts from kubefirst.com show up in the new space in konstruct.io
  we spend a few weeks using these new charts, incorporate them in our systems, do testing and migration work with a bunch of builds and publishes, which will publish more charts to the new chartmusem
  --- then after a bunch of natural updates on both sides of the house (publishes have been occurring on both kubefirst and konstruct charts) ---
  do a final migration using the same dispatch when we’re cutting over, and any new published charts from charts.kubefirst.com will just lay overtop and show up at charts.konstruct.io? or is there an operational hole in my swing?

mirror-charts.yaml
REGISTRY_DESTINATION: "https://chartmuseum.freegitopsmagic.com/"
https://github.com/[konstructio/charts-mirror](https://github.com/konstructio/charts-mirror)|konstructio/charts-mirrorkonstructio/charts-mirror

Patrick:
Sounds correct, the only part that's missing from the train of thought is to change the credentials/secrets, so besides this line:
https://github.com/konstructio/charts-mirror/blob/main/.github/workflows/mirror-charts.yaml#L11
You also need to ensure the appropriate secret is mounted here:
https://github.com/konstructio/charts-mirror/blob/main/.github/workflows/mirror-charts.yaml#L86-L88
https://github.com/konstructio/charts-mirror/blob/main/.github/workflows/mirror-charts.yaml#L99-L101

The other worth thing to note is that this also runs on a cronjob weekly, at one point we might want to disable that and/or only do the part to download locally, but we can cross that bridge when we get there 😄