ami/tl-vikunja
1
0
Fork 0
Code Activity

Cleanup references to make

Browse Source
This commit is contained in:
kolaente
2020-09-03 17:18:41 +02:00
parent d359130bcf
commit 8da7db3e26
6 changed files with 17 additions and 264 deletions
Download Patch File Download Diff File Expand all files Collapse all files

4
docs/content/doc/development/development.md
View File

@ -51,7 +51,7 @@ git fetch --all --prune
{{< /highlight >}}
This should provide a working development environment for Vikunja. Take a look at the Makefile to get an overview about
the available tasks. The most common tasks should be `make test` which will start our test environment and `make build`
the available tasks. The most common tasks should be `mage test:unit` which will start our test environment and `mage build:build`
which will build a vikunja binary into the working directory. Writing test cases is not mandatory to contribute, but it
is highly encouraged and helps developers sleep at night.
@ -62,4 +62,4 @@ That’s it! You are ready to hack on Vikunja. Test changes, push them to the re
Each Vikunja release contains all static assets directly compiled into the binary.
To prevent this during development, use the `dev` tag when developing.
See the [make docs](make.md#statically-compile-all-templates-into-the-binary) about how to compile with static assets for a release.
See the [mage docs](mage.md#statically-compile-all-templates-into-the-binary) about how to compile with static assets for a release.

8
docs/content/doc/development/structure.md
View File

@ -47,7 +47,7 @@ This document will explain what these mean and what you can find where.
## Root level
The root directory is where [the config file]({{< ref "../setup/config.md">}}), [Makefile]({{< ref "make.md">}}), license, drone config,
The root directory is where [the config file]({{< ref "../setup/config.md">}}), [Magefile]({{< ref "mage.md">}}), license, drone config,
application entry point (`main.go`) and so on are located.
## docker
@ -152,11 +152,11 @@ Every handler function which does not use the standard web handler should live h
### static
All static files generated by `make generate` live here.
All static files generated by `mage generate` live here.
### swagger
This is where the [generated]({{< ref "make.md#generate-swagger-definitions-from-code-comments">}} [api docs]({{< ref "../usage/api.md">}}) live.
This is where the [generated]({{< ref "mage.md#generate-swagger-definitions-from-code-comments">}} [api docs]({{< ref "../usage/api.md">}}) live.
You usually don't need to touch this package.
### user
@ -175,7 +175,7 @@ See their function definitions for instructions on how to use them.
### version
The single purpouse of this package is to hold the current vikunja version which gets overridden through build flags
each time `make release` or `make build` is run.
each time `mage release` or `mage build` is run.
It is a seperate package to avoid import cycles with other packages.
## REST-Tests

8
docs/content/doc/development/test.md
View File

@ -10,10 +10,10 @@ menu:
# Testing
You can run unit tests with [our `Makefile`]({{< ref "make.md">}}) with
You can run unit tests with [our `Magefile`]({{< ref "mage.md">}}) with
{{< highlight bash >}}
make test
mage test:unit
{{< /highlight >}}
### Running tests with config
@ -36,12 +36,12 @@ When you add a new test case which requires new database entries to test against
# Integration tests
All integration tests live in `pkg/integrations`.
You can run them by executing `make integration-test`.
You can run them by executing `mage test:integration`.
The integration tests use the same config and fixtures as the unit tests and therefor have the same options available,
see at the beginning of this document.
To run integration tests, use `make integration-test`.
To run integration tests, use `mage test:integration`.
# Initializing db fixtures when writing tests