all: do not commit generated JS/CSS to source control (#148)
Closes #125 Closes #40 Among other things, this moves all of the asset generation to run within the context of an npm script. Developer documentation stubs have been added so that people can get started more easily. The top-level Dockerfile (which is no longer used in production) has been removed as its presence has been causing confusion. This changeset will break it anyways. These changes will make for less "repo churn" as the static assets are built and rebuilt, at the cost of making the build step more complicated for downstream packagers. If this becomes a burden, we can explore making a "release tarball" that contains pre-massaged outputs.
This commit is contained in:
parent
bb4f49cfd9
commit
937f1dd330
28 changed files with 223 additions and 77 deletions
|
|
@ -14,6 +14,9 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
|
|||
- Hide the directory listings for Anubis' internal static content
|
||||
- Changed `--debug-x-real-ip-default` to `--use-remote-address`, getting the IP address from the request's socket address instead.
|
||||
- DroneBL lookups have been disabled by default
|
||||
- Static asset builds are now done on demand instead of the results being committed to source control
|
||||
- The Dockerfile has been removed as it is no longer in use
|
||||
- Developer documentation has been added to the docs site
|
||||
|
||||
## v1.15.0
|
||||
|
||||
|
|
|
|||
8
docs/docs/developer/_category_.json
Normal file
8
docs/docs/developer/_category_.json
Normal file
|
|
@ -0,0 +1,8 @@
|
|||
{
|
||||
"label": "Developer guides",
|
||||
"position": 50,
|
||||
"link": {
|
||||
"type": "generated-index",
|
||||
"description": "Guides and suggestions to make Anubis development go smoothly for everyone."
|
||||
}
|
||||
}
|
||||
31
docs/docs/developer/code-quality.md
Normal file
31
docs/docs/developer/code-quality.md
Normal file
|
|
@ -0,0 +1,31 @@
|
|||
---
|
||||
title: Code quality guidelines
|
||||
---
|
||||
|
||||
When submitting code to Anubis, please take the time to consider the fact that this project is security software. If things go bad, bots can pummel sites into oblivion. This is not ideal for uptime.
|
||||
|
||||
As such, code reviews will be a bit more strict than you have seen in other projects. This is not people trying to be mean, this is a side effect of taking the problem seriously.
|
||||
|
||||
When making code changes, try to do the following:
|
||||
|
||||
- If you're submitting a bugfix, add a test case for it
|
||||
- If you're changing the JavaScript, make sure the integration tests pass (`npm run test:integration`)
|
||||
|
||||
## Commit messages
|
||||
|
||||
Anubis follows the Go project's conventions for commit messages. In general, an ideal commit message should read like this:
|
||||
|
||||
```text
|
||||
path/to/folder: brief description of the change
|
||||
|
||||
If the change is subtle, has implementation consequences, or is otherwise
|
||||
not entirely self-describing: take the time to spell out why. If things
|
||||
are very subtle, please also amend the documentation accordingly
|
||||
```
|
||||
|
||||
The subject of a commit message should be the second half of the sentence "This commit changes the Anubis project to:". Here's a few examples:
|
||||
|
||||
- `disable DroneBL by default`
|
||||
- `port the challenge to WebAssembly`
|
||||
|
||||
The extended commit message is also your place to give rationale for a new feature. When maintainers are reviewing your code, they will use this to figure out if the burden from feature maintainership is worth the merge.
|
||||
57
docs/docs/developer/local-dev.md
Normal file
57
docs/docs/developer/local-dev.md
Normal file
|
|
@ -0,0 +1,57 @@
|
|||
---
|
||||
title: Local development
|
||||
---
|
||||
|
||||
:::note
|
||||
|
||||
TL;DR: `npm ci && npm run dev`
|
||||
|
||||
:::
|
||||
|
||||
Anubis requires the following tools to be installed to do local development:
|
||||
|
||||
- [Go](https://go.dev) - the programming language that Anubis is written in
|
||||
- [esbuild](https://esbuild.github.io/) - the JavaScript bundler Anubis uses for its production JS assets
|
||||
- [Node.JS & NPM](https://nodejs.org/en) - manages some build dependencies
|
||||
- `gzip` - compresses production JS (part of coreutils)
|
||||
- `zstd` - compresses production JS
|
||||
- `brotli` - compresses production JS
|
||||
|
||||
If you have [Homebrew](https://brew.sh) installed, you can install all the dependencies with one command:
|
||||
|
||||
```text
|
||||
brew bundle
|
||||
```
|
||||
|
||||
If you don't, you may need to figure out equivalents to the packages in Homebrew.
|
||||
|
||||
## Running Anubis locally
|
||||
|
||||
```text
|
||||
npm run dev
|
||||
```
|
||||
|
||||
Or to do it manually:
|
||||
|
||||
- Run `npm run assets` every time you change the CSS/JavaScript
|
||||
- `go run ./cmd/anubis` with any CLI flags you want
|
||||
|
||||
## Building JS/CSS assets
|
||||
|
||||
```text
|
||||
npm run assets
|
||||
```
|
||||
|
||||
If you change the build process, make sure to update `build.sh` accordingly.
|
||||
|
||||
## Production-ready builds
|
||||
|
||||
```text
|
||||
npm run container
|
||||
```
|
||||
|
||||
This builds a prod-ready container image with [ko](https://ko.build). If you want to change where the container image is pushed, you need to use environment variables:
|
||||
|
||||
```text
|
||||
DOCKER_REPO=registry.host/org/repo DOCKER_METADATA_OUTPUT_TAGS=registry.host/org/repo:latest npm run container
|
||||
```
|
||||
7
docs/docs/developer/signed-commits.md
Normal file
7
docs/docs/developer/signed-commits.md
Normal file
|
|
@ -0,0 +1,7 @@
|
|||
---
|
||||
title: Signed commits
|
||||
---
|
||||
|
||||
Anubis requires developers to sign their commits. This is done so that we can have a better chain of custody from contribution to owner. For more information about commit signing, [read here](https://www.freecodecamp.org/news/what-is-commit-signing-in-git/).
|
||||
|
||||
We do not require GPG. SSH signed commits are fine. For an overview on how to set up commit signing with your SSH key, [read here](https://dev.to/ccoveille/git-the-complete-guide-to-sign-your-commits-with-an-ssh-key-35bg).
|
||||
Loading…
Add table
Add a link
Reference in a new issue