👀 Un outil de la #Forge à tester pour un usage en #EMI #MiXAP . Repéré par @fidel Dis @missionemiaclimoges . Tu en penses-quoi ? 😉
@framaka @ladigitale @imarfisi
https://outilstice.com/2025/11/mixap-donnez-vie-a-vos-documents-papier-avec-la-realite-augmentee/
👀 Un outil de la #Forge à tester pour un usage en #EMI #MiXAP . Repéré par @fidel Dis @missionemiaclimoges . Tu en penses-quoi ? 😉
@framaka @ladigitale @imarfisi
https://outilstice.com/2025/11/mixap-donnez-vie-a-vos-documents-papier-avec-la-realite-augmentee/
🎥Le replay de la présentation de “Calendrier de l’avent” est en ligne!
Une application libre proposée par Cédric @eyssette pour créer facilement un calendrier collaboratif en markdown.
👉🏼 https://calendrier-avent.forge.apps.education.fr/
Replay
👉🏼 https://edurl.fr/primtime-replay
D’autres ressources libres sur la Forge primaire :
👉🏼 https://primaire.forge.apps.education.fr/
#ForgePrimaire #markdown #Forge #TeamERUN #TeamPE #TeamPROF @lelibreedu
🎥Le replay de la présentation de “Calendrier de l’avent” est en ligne!
Une application libre proposée par Cédric @eyssette pour créer facilement un calendrier collaboratif en markdown.
👉🏼 https://calendrier-avent.forge.apps.education.fr/
Replay
👉🏼 https://edurl.fr/primtime-replay
D’autres ressources libres sur la Forge primaire :
👉🏼 https://primaire.forge.apps.education.fr/
#ForgePrimaire #markdown #Forge #TeamERUN #TeamPE #TeamPROF @lelibreedu
Check it out! @forgejo has a great presence on #Wikipedia now:
Check it out! @forgejo has a great presence on #Wikipedia now:
What about plugins in GitRoot? They are essential. Without them, you just have #Git repositories; with them, you get a full-featured #forge.
Currently, plugins are #wasm binaries following the #wasi specification. They can read/write to your Git repository and web space (files in a directory).
They are triggered on every push diff, depending on your `.gitroot/plugins.yml` configuration. More on plugin rights: https://gitroot.dev/doc/how-tos/plugin_rights.html
1/3
What about plugins in GitRoot? They are essential. Without them, you just have #Git repositories; with them, you get a full-featured #forge.
Currently, plugins are #wasm binaries following the #wasi specification. They can read/write to your Git repository and web space (files in a directory).
They are triggered on every push diff, depending on your `.gitroot/plugins.yml` configuration. More on plugin rights: https://gitroot.dev/doc/how-tos/plugin_rights.html
1/3
How does GitRoot handle security without a database or an API?
It's a system based entirely on your repo's configuration and how git works.
When you create a repo, your public SSH key is saved in the file: `.gitroot/users.yml`. You are automatically added to the `owner` group in that file. This group is marked to manage your default branch (main by default).
So, what does this mean in practice?
If you push to main: GitRoot checks your SSH key, sees you're the owner, and accepts the push. If someone else tries to push to main: their SSH key doesn't match the owner group. GitRoot rejects the push.
But here's the cool part: anyone can create a new branch (feature-fix for example) and push their changes to that branch.
This creates a perfect workflow: you, as the owner, remain the sole manager of the main branch and are the only one who can review and merge changes from other contributors. Contributors don't need to fork for contributions.
It's your repository, and you have the freedom to configure these rules however you want, right in that YAML file.
Learn more about user management: https://gitroot.dev/doc/#users
More tips:
- disable anonymous pushes: https://gitroot.dev/doc/how-tos/no_anonymous_user.html
- let all contributors write to all branches: https://gitroot.dev/doc/how-tos/contributors_can_write_all.html
#git #forge #configuration #ssh #security #devops
How does GitRoot handle security without a database or an API?
It's a system based entirely on your repo's configuration and how git works.
When you create a repo, your public SSH key is saved in the file: `.gitroot/users.yml`. You are automatically added to the `owner` group in that file. This group is marked to manage your default branch (main by default).
So, what does this mean in practice?
If you push to main: GitRoot checks your SSH key, sees you're the owner, and accepts the push. If someone else tries to push to main: their SSH key doesn't match the owner group. GitRoot rejects the push.
But here's the cool part: anyone can create a new branch (feature-fix for example) and push their changes to that branch.
This creates a perfect workflow: you, as the owner, remain the sole manager of the main branch and are the only one who can review and merge changes from other contributors. Contributors don't need to fork for contributions.
It's your repository, and you have the freedom to configure these rules however you want, right in that YAML file.
Learn more about user management: https://gitroot.dev/doc/#users
More tips:
- disable anonymous pushes: https://gitroot.dev/doc/how-tos/no_anonymous_user.html
- let all contributors write to all branches: https://gitroot.dev/doc/how-tos/contributors_can_write_all.html
#git #forge #configuration #ssh #security #devops
I'm just starting thinking it through. It basically means Outsystems develops a proprietary platform that engages users to share their own works under OS licenses with other users to further improve the usage of Outsystems by drastically extending its adaptability, scope and use-cases.
But the platform stays proprietary and any contributions stay dependent on the platform.
While I on one hand appreciate that Outsystems encourages its community to share developments through OS licenses, on the other hand it might only serve to increase dependency on its proprietary roots.
Open source community building as a sweetener for monopolistic dependencies?
What do you think?
#outsystems #forge #opensource #dependency #publicadministration
Why gitroot is different? Why the need to build another forge? Just 2 concepts I have not found in all other forges:
- no database + no api == no vendor locking, your data is just aside your code. By data I mean: users, branches rights but also issues, boards and pipelines... Clone your repo all your data is on your computer, mirror to another forge (preferably @Codeberg 😍) and you have a backup.
- simple at start, grow only if needed == plugin based, you want to do a simple static blog: use only apex plugin. You want a full forge install ladybug, silo, grafter, pollen plugins and many more. Don't waste your server resources with unused features.
This 2 concepts drive the code every day. It's not simple (to code) but at the end of every day I'm happy with a simple (to use) forge.
This 2 concepts permit to do more with less and that is exactly what I want for my forge.
Something not clear here or in https://gitroot.dev please ask here, in DM, at contact@gitroot.dev, or in issues and I will try to explain.
Edit: added missing hashtags
#git #forge #selfhost #foss
Say hello to the new plugin: `Hop`. Thanks to the new #rust plugin-sdk we can code plugins in rust!
This plugin will be the base of the CI/CD of GitRoot. It permit to execute process on the host server.
This process could be executed in an oci container #podman or #docker
But for now I want to try to exec in a #chroot jail. The approache is much more in the spirit of GitRoot (less ressource needed, more simple to use... or not will see...) even if I know oci container are mandatory.
It will be the responsibility of the instance administrator to choose what strategy they want to offer to their users.
#git #forge #cicd #rustlang
Say hello to the new plugin: `Hop`. Thanks to the new #rust plugin-sdk we can code plugins in rust!
This plugin will be the base of the CI/CD of GitRoot. It permit to execute process on the host server.
This process could be executed in an oci container #podman or #docker
But for now I want to try to exec in a #chroot jail. The approache is much more in the spirit of GitRoot (less ressource needed, more simple to use... or not will see...) even if I know oci container are mandatory.
It will be the responsibility of the instance administrator to choose what strategy they want to offer to their users.
#git #forge #cicd #rustlang
The new Laravel Forge redesign is growing on me, I do like how it includes the commit message to better track deployments!
Why gitroot is different? Why the need to build another forge? Just 2 concepts I have not found in all other forges:
- no database + no api == no vendor locking, your data is just aside your code. By data I mean: users, branches rights but also issues, boards and pipelines... Clone your repo all your data is on your computer, mirror to another forge (preferably @Codeberg 😍) and you have a backup.
- simple at start, grow only if needed == plugin based, you want to do a simple static blog: use only apex plugin. You want a full forge install ladybug, silo, grafter, pollen plugins and many more. Don't waste your server resources with unused features.
This 2 concepts drive the code every day. It's not simple (to code) but at the end of every day I'm happy with a simple (to use) forge.
This 2 concepts permit to do more with less and that is exactly what I want for my forge.
Something not clear here or in https://gitroot.dev please ask here, in DM, at contact@gitroot.dev, or in issues and I will try to explain.
Edit: added missing hashtags
#git #forge #selfhost #foss
Is there anyone using Radicle for collaboration (as a git forge)? I really like the idea of decentralised git hosting. By quickly trying out radicle-desktop, it seems to have most of the features I need (namely, issues and patches). I'm still looking if there's CI/CD, but maybe that needs to be done separately.
#git #forge #radicle
Is there anyone using Radicle for collaboration (as a git forge)? I really like the idea of decentralised git hosting. By quickly trying out radicle-desktop, it seems to have most of the features I need (namely, issues and patches). I'm still looking if there's CI/CD, but maybe that needs to be done separately.
#git #forge #radicle