button works deployed

integrating this with tests like #323 needs a conscious approach on if/how to distinguish metadata from user input at the module interface.
currently, metadata has still been either hard-coded, or read in from files.

the place to deploy to would be required to test this tho, raising the question of whether to:

use TF object type inputs to group user input and a newly distinguished meta explicit input group. this would keep it clear on which part would be relevant for front-ends, all the more relevant since #285, but seems less elegant for cluttering the TF interface, as top level inputs get convenient interfaces such as -var and TF_VAR_*.
de-hardcoding metadata using alternate channels such as files and environment variables, as we may not need to otherwise expose make these in the first place:
- npins deps should not need to be pluggable, and originally were calculated within TF - since having been decoupled only as a performance improvement
- IPs eventually should not need setting, and are only still hard-coded until #113
- domains are similar as IPs there (#110)
- maybe misc stuff, see #314
for the moment exposing metadata needed for testing over the same interface as user input - temporarily inelegant for the purpose of visual demos, tho otherwise maybe offering a simpler approach (until #313) for testing purposes for facilitating grouping of metadata with service, while simultaneously perhaps being a bit more explicit about our technical debt.

for the purpose of testing this story (short of lumping all the further automation on), i feel option 3 may be the lesser evil for the moment.

integrating this with tests like #323 needs a conscious approach on if/how to distinguish metadata from user input at the module interface. currently, metadata has still been either hard-coded, or read in from files. the place to deploy to would be required to test this tho, raising the question of whether to: 1. use TF object type inputs to group user input and a newly distinguished meta explicit input group. this would keep it clear on which part would be relevant for front-ends, all the more relevant since #285, but seems less elegant for cluttering the TF interface, as top level inputs [get convenient interfaces](https://developer.hashicorp.com/terraform/language/values/variables) such as `-var` and `TF_VAR_*`. 1. de-hardcoding metadata using alternate channels such as files and environment variables, as we may not need to otherwise expose make these in the first place: - npins deps should not need to be pluggable, and originally were calculated within TF - since having been decoupled only as a performance improvement - IPs *eventually* should not need setting, and are only still hard-coded until #113 - domains are similar as IPs there (#110) - maybe misc stuff, see #314 1. for the moment exposing metadata needed for testing over the same interface as user input - temporarily inelegant for the purpose of visual demos, tho otherwise maybe offering a simpler approach (until #313) for testing purposes for facilitating grouping of metadata with service, while simultaneously perhaps being a bit more explicit about our technical debt. for the purpose of testing this story (short of lumping all the further automation on), i feel option 3 may be the lesser evil for the moment.

fricklerhandwerk commented

2025-05-02 08:49:16 +02:00

Owner

What exactly is the metadata here? Other than that, 👍for making tech debt explicit.

kiara commented

2025-05-05 18:23:56 +02:00

Author

Owner

@fricklerhandwerk the meta-data includes:

calculated in TF
- code hash
calculated before TF
- pins
hard-coded stuff (now updated at #314)

edit: to be clear, what i intended to propose making explicit for now is less 'all of that' more 'what we actually need for testing already', for now

@fricklerhandwerk the meta-data includes: - calculated in TF - code hash - calculated before TF - pins - hard-coded stuff (now updated at #314) edit: to be clear, what i intended to propose making explicit for now is less 'all of that' more 'what we actually need for testing already', for now

kiara force-pushed tofu from 4065675b99 to 1019ac15b0

2025-05-05 20:23:01 +02:00

Compare

kiara added 1 commit 2025-05-09 15:16:18 +02:00

account for 285

/ check-pre-commit (pull_request) Failing after 11s

Details

/ check-peertube (pull_request) Successful in 18s

Details

/ check-panel (pull_request) Successful in 1m20s

Details

/ check-deployment-basic (pull_request) Successful in 11m36s

Details

/ check-launch (pull_request) Successful in 56s

Details

90cda83039

fricklerhandwerk commented

2025-06-16 10:27:48 +02:00

Owner

Shall we close this, as it seems to be mostly exploratory code? The TF migration is in the other PR, so what's left here as substance?

kiara commented

2025-06-16 11:47:39 +02:00

Author

Owner

@fricklerhandwerk wrote in Fediversity/Fediversity#307 (comment):

Shall we close this, as it seems to be mostly exploratory code? The TF migration is in the other PR, so what's left here as substance?

the intended division of labor wasn't exploratory vs real, rather focus on user applications vs infra - tho tbf a code move on the latter's part has currently affected code here as well, making it more of a superset of this branch (tho it might be missing recent bits).
if we are to merge things piece-meal (as you expressed before), then i'm not sure going for just that one would match that intent.

i would propose instead ensuring this one matches the move over there, such as to reduce diffs while keeping PRs not too much bigger than needed.

@fricklerhandwerk wrote in https://git.fediversity.eu/Fediversity/Fediversity/pulls/307#issuecomment-7819: > Shall we close this, as it seems to be mostly exploratory code? The TF migration is in the other PR, so what's left here as substance? the intended division of labor wasn't exploratory vs real, rather focus on user applications vs infra - tho tbf a code move on the latter's part has currently affected code here as well, making it more of a superset of this branch (tho it might be missing recent bits). if we are to merge things piece-meal (as you expressed before), then i'm not sure going for just that one would match that intent. i would propose instead ensuring this one matches the move over there, such as to reduce diffs while keeping PRs not too much bigger than needed.

kiara commented

2025-06-16 11:53:12 +02:00

Author

Owner

in retrospect, i may not be certain what other PR you're referring to. i assumed the infra one, but you may have intended the tofu-test branch, which is kinda intended as a successor for this branch, tho i'd put off opening a PR over forgejo PRs being annoying about rebases.
if that one was your intent, i could open one for that to replace this one.

in retrospect, i may not be certain what other PR you're referring to. i assumed the infra one, but you may have intended the [`tofu-test`](https://git.fediversity.eu/Fediversity/Fediversity/compare/main...kiara/Fediversity:tofu-test) branch, which is kinda intended as a successor for this branch, tho i'd put off opening a PR over forgejo PRs being annoying about rebases. if that one was your intent, i could open one for that to replace this one.

fricklerhandwerk commented

2025-06-16 16:06:11 +02:00

Owner

I meant Fediversity/Fediversity#319, which seems to be somewhat similar in scope and nature.

I meant https://git.fediversity.eu/Fediversity/Fediversity/pulls/319, which seems to be somewhat similar in scope and nature.

kiara commented

2025-06-16 16:22:44 +02:00

Author

Owner

ok in that case see Fediversity/Fediversity#307 (comment)

ok in that case see https://git.fediversity.eu/Fediversity/Fediversity/pulls/307#issuecomment-7825

kiara added 1 commit 2025-06-17 08:33:19 +02:00

move files in line with tf-infra

/ check-pre-commit (pull_request) Failing after 20s

Details

/ check-peertube (pull_request) Successful in 23s

Details

/ check-panel (pull_request) Failing after 20s

Details

/ check-deployment-basic (pull_request) Successful in 13m1s

Details

/ check-launch (pull_request) Failing after 3s

Details

e916c606d1

kiara changed title from ~~buttons works deployed~~ to button works deployed

2025-06-27 12:06:20 +02:00

kiara force-pushed tofu from e916c606d1 to bf4df5500a

2025-08-07 14:05:17 +02:00

Compare

/ check-pre-commit (pull_request) Failing after 17s

Required

Details

/ check-data-model (pull_request) Successful in 31s

Required

Details

/ check-mastodon (pull_request) Successful in 22s

Required

Details

/ check-peertube (pull_request) Successful in 23s

Required

Details

/ check-panel (pull_request) Failing after 31s

Required

Details

/ check-deployment-basic (pull_request) Successful in 36s

Required

Details

/ check-deployment-cli (pull_request) Successful in 43s

Required

Details

/ check-deployment-panel (pull_request) Failing after 13s

Required

Details

/ check-resources (pull_request) Failing after 59s

Required

Details

/ check-launch (pull_request) Failing after 3s

Details

This pull request has changes conflicting with the target branch.

.forgejo/workflows/ci.yaml
infra/makeInstallerIso.nix
infra/proxmox-provision.sh
infra/proxmox-remove.sh

View command line instructions

Checkout

From your project repository, check out a new branch and test the changes.

git fetch -u tofu:kiara-tofu

git checkout kiara-tofu

Rows
Columns

button works deployed #307

Checkout