forge
/
site
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

Update specs submodule 

and fix a few typos
This commit is contained in:
southerntofu 2022-02-24 17:58:05 +01:00
parent d345a62f8a
commit 1db0993fac
3 changed files with 6 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

3
.gitmodules vendored
View File

@ -7,3 +7,6 @@
[submodule "submodules/endpoints"]
path = submodules/endpoints
url = https://tildegit.org/forge/endpoints
[submodule "submodules/specs"]
path = submodules/specs
url = https://tildegit.org/forge/specs

4
content/_index.md
View File

@ -30,7 +30,7 @@ Apart from the remote webforge (Gitea, Gitlab, or Github), we have three compone
The reason for calling a 3rd party program to perform the secret validation is detailed in the [Security section](#security). The short version is so that the web server cannot read the actual secrets. This is particularly useful in the case of shared pubnix/tilde servers where:
- the server operator is trusted, but other users on the machine aren't
- all web processes run as a system user (such as `http` or `ẁww-data`)
- all web processes run as a system user (such as `http` or `www-data`)
- the user has access to a shell account where they can setup programs and set the suid bit so that the web process can run *forgecheck* under their account
Once validation is performed, *forgebuild* will pick up the tasks to run in one of two ways:
@ -48,7 +48,7 @@ The forgesuite project is driven by technical and political motivations. Our ove
## Don't ask maintainers for permission, just forge on!
All major CI/CD plateforms consider the repository itself should contain the tasks to be run, for example in a `.gitlab-ci.yml` file. This top-down deployment model is well suited to an organization controling the whole of its software supply chain, but is a severe restriction to 3rd party involvement, which mostly hinders volunteer-run projects.
All major CI/CD platforms consider the repository itself should contain the tasks to be run, for example in a `.gitlab-ci.yml` file. This top-down deployment model is well suited to an organization controling the whole of its software supply chain, but is a severe restriction to 3rd party involvement, which mostly hinders volunteer-run projects.
The forge suite adopts an opposite approach, where anyone can receive updates from remote repositories, and run the tasks they wish. This allows anyone within or without your projects to setup new test suites, benchmarks, and integrations. The tasks and configuration can also be shared (across your machines, or with everyone else) in a repository, as the secrets can reside anywhere else on the machine. The applications are endless and should benefit your projects in many ways.

1
submodules/specs Submodule

@ -0,0 +1 @@
Subproject commit 66332ae7b1d36b468e72e7cdcebc966584072ca5