ADR about Kinto Admin UI releasing and packaging

[leplatrem]

No description provided.

[alexcottner]

Something I started thinking about that we haven't addressed in this ADR yet. If kinto-admin has an updated release made, but no code changes have happened in remote-settings that would trigger a new release for remote-settings, how does our action know to publish a new build?

Seems like there are 3 options to me:

1. Do math. If our previous release of remote-settings happened before the most recent release of kinto-admin, assume we need to do a new build.
2. Receive a push from kinto-admin actions that would commit an updated version number to us.
3. Pull from kinto-admin and compare it's current release version with what we have. Then update our version number after a release goes out.

[leplatrem]

Something I started thinking about that we haven't addressed in this ADR yet. If kinto-admin has an updated release made, but no code changes have happened in remote-settings that would trigger a new release for remote-settings, how does our action know to publish a new build?

I added a note about this, mentioning the option to have a "fake" package.json file so that Dependabot keeps it up-to-date in the Remote Settings repo for us

[alexcottner]

Kinto already uses this file to track which version of the admin to pull/build. https://github.com/Kinto/kinto/blob/master/kinto/plugins/admin/VERSION

We can do something similar to keep it consistent.

[leplatrem]

We can do something similar to keep it consistent.

If the fake package.json trick works, I would do the same in the kinto instead of this VERSION file. Using jq here should be straightforward