fediversity/fediversity

Fork 10

reference front-end is decoupled from version of configuration module #304

New issue

Closed

opened 2025-04-08 16:47:01 +02:00 by kiara · 1 comment

kiara commented

2025-04-08 16:47:01 +02:00

Owner

As a Fediversity user,
I want a front-end not tightly coupled with the versioning of configuration modules,
so that I may deploy code without having to worry about front-enders' concerns trumping my version preferences.

implementation notes

the deployment module should be separate from the Django code, so that we may explicitly specify what version to invoke deployment for - potentially even including forks (see #100).
to achieve this, a separated repo for the deployment module should specify how code-bases would (given a version) know how to invoke it:

django-jsonform (see #628, fixed in #895) to serve by API from our current panel implementation
generated json-schema of valid options (#195)
- sample ui-schema that may be used in visualization (#987)
implement version in the panel data schema to support disparities from migration (#100)
- similarly allowing it to inspect its recommended version (if no longer coupled by mono-repo) to use as its default value for new deployments
- in the migration string (#77) add a fetchTree input identifying a Fediversity configuration module source, including pinned version (rev)
document implementation/usage
- sample implementation in panel/ may function as documentation of usage

(changed files paths mentioned following #274)

any environment
- panel/views.py#deploy
- launch/tf.nix
- document handling incoming updates for stored configurations (#159)
environment-specific
- prod
  - launch/tf-env.nix
  - document storing state
- dev
  - launch/default.nix
  - panel/env.nix

**As** a Fediversity user, **I want** a front-end not tightly coupled with the versioning of configuration modules, **so that** I may deploy code without having to worry about front-enders' concerns trumping my version preferences. ## implementation notes the deployment module should be separate from the Django code, so that we may explicitly specify what version to invoke deployment for - potentially even including forks (see #100). to achieve this, a separated repo for the deployment module should specify how code-bases would (given a version) know how to invoke it: - [x] [`django-jsonform`](https://github.com/bhch/django-jsonform) (see #628, fixed in #895) to serve by API from our current `panel` implementation - [x] generated json-schema of valid options (#195) - sample ui-schema that may be used in visualization (#987) - [x] implement version in the [`panel` data schema](https://git.fediversity.eu/Fediversity/meta/pulls/31/files) to support disparities from migration (#100) - [x] similarly allowing it to inspect its recommended version (if no longer coupled by mono-repo) to use as its default value for new deployments - in the migration string (#77) add a [`fetchTree`](https://noogle.dev/f/builtins/fetchTree) `input` identifying a Fediversity configuration module source, including pinned version (`rev`) - document implementation/usage - sample implementation in `panel/` may function as documentation of usage <details> <summary> (changed files paths mentioned following #274) </summary> - any environment - `panel/views.py#deploy` - `launch/tf.nix` - document handling incoming updates for stored configurations (#159) - environment-specific - prod - `launch/tf-env.nix` - document storing state - dev - `launch/default.nix` - `panel/env.nix` </details>

kiara added a new dependency

2025-04-08 16:47:14 +02:00

#303 decouple mono-repo

kiara added a new dependency

2025-04-08 16:47:21 +02:00

#206 user control over update timing

kiara added a new dependency

2025-04-08 16:47:37 +02:00

#100 migrating application data between hosting providers

kiara added a new dependency

2025-04-08 16:49:48 +02:00

#228 [D2.3] brought into production [2027-11-01]

kiara added this to the Fediversity project

2025-04-14 11:27:14 +02:00

kiara removed a dependency

2025-04-14 11:27:40 +02:00

#303 decouple mono-repo

kiara referenced this issue

2025-04-14 11:28:10 +02:00

decouple mono-repo #303

kiara added a new dependency

2025-04-17 20:38:25 +02:00

#275 Generate Django forms from deployment options

kiara added the

type unclear

label

2025-05-01 12:19:18 +02:00

~~kiara referenced this issue 2025-05-20 19:56:51 +02:00~~

migrating application data between hosting providers #100

kiara referenced this issue

2025-05-27 16:01:19 +02:00

panel bundled into Fediversity configuration #342

kiara added

type: user story

and removed

type unclear

labels

2025-06-01 10:23:14 +02:00

kiara changed title from ~~allow control over version of module deployed~~ to reference front-end decoupled from template version

2025-06-01 16:52:00 +02:00

kiara changed title from ~~reference front-end decoupled from template version~~ to reference front-end decoupled from version of configuration module

2025-06-02 10:22:55 +02:00

kiara changed title from ~~reference front-end decoupled from version of configuration module~~ to reference front-end is decoupled from version of configuration module

2025-06-02 12:52:04 +02:00

kiara removed a dependency

2025-06-02 12:54:05 +02:00

#100 migrating application data between hosting providers

kiara commented

2025-06-02 12:55:26 +02:00

Author

Owner

removed from deps of #100 as technically this isn't mandatory to implement the principle, just in production where versions may not match