mirror of
https://github.com/Bubberstation/Bubberstation.git
synced 2026-08-24 13:38:41 +01:00
[MIRROR] Add documentation for CI [MDB IGNORE] (#16542)
* Add documentation for CI * merge conflict in contrib Co-authored-by: Mothblocks <35135081+Mothblocks@users.noreply.github.com> Co-authored-by: tastyfish <crazychris32@gmail.com>
This commit is contained in:
SkyratBot
co-authored by
Mothblocks
tastyfish
Mothblocks
tastyfish
parent
c973c872e7
commit
797bf51117
+8
-11
@@ -105,17 +105,14 @@ Things you **CAN'T** do:
|
||||
|
||||
#### Misc
|
||||
|
||||
[Policy configuration system](./guides/POLICYCONFIG.md)
|
||||
|
||||
[Hard deletes](./guides/HARDDELETES.md)
|
||||
|
||||
[UI Development](../tgui/README.md)
|
||||
|
||||
[AI Datums](../code/datums/ai/making_your_ai.md)
|
||||
|
||||
[MC Tab Guide](./guides/MC_tab.md)
|
||||
|
||||
[Embedding tgui components in chat](../tgui/docs/chat-embedded-components.md)
|
||||
- [AI Datums](../code/datums/ai/making_your_ai.md)
|
||||
- [Embedding TGUI Components in Chat](../tgui/docs/chat-embedded-components.md)
|
||||
- [Hard Deletes](./guides/HARDDELETES.md)
|
||||
- [MC Tab Guide](./guides/MC_tab.md)
|
||||
- [Policy Configuration System](./guides/POLICYCONFIG.md)
|
||||
- [Required Tests (Continuous Integration)](./guides/CI.md)
|
||||
- [UI Development](../tgui/README.md)
|
||||
- [Visual Effects and Systems](./guides/VISUALS.md)
|
||||
## Pull Request Process
|
||||
|
||||
There is no strict process when it comes to merging pull requests. Pull requests will sometimes take a while before they are looked at by a maintainer; the bigger the change, the more time it will take before they are accepted into the code. Every team member is a volunteer who is giving up their own time to help maintain and contribute, so please be courteous and respectful. Here are some helpful ways to make it easier for you and for the maintainers when making a pull request.
|
||||
|
||||
@@ -0,0 +1,55 @@
|
||||
# Required Tests (Continuous Integration)
|
||||
|
||||
> ℹ️ This is not the documentation for *writing* a test. You can find that in [the unit tests folder](../../code/modules/unit_tests/README.md).
|
||||
|
||||
Every pull request runs through a series of checks and tests to ensure its quality.
|
||||
|
||||
|
||||
|
||||
If after reading this guide you still do not understand why a check suite is failing, either ask on your pull request or ask in the coding channel on the Discord.
|
||||
|
||||
## Run Linters
|
||||
|
||||
The [linters](https://en.wikipedia.org/wiki/Lint_(software)) check the maps and code for common mistakes. This includes things like:
|
||||
|
||||
- Files not being included in the .dme
|
||||
- Misspelling Nanotrasen as NanoTrasen
|
||||
- Unformatted map files
|
||||
|
||||
Sometimes linters will fail, but you won't see anything in the "Run Linters" tab. If you open up the action, it might look like this:
|
||||
|
||||
|
||||
|
||||
Specifically, notice that "Run Linters" has failed, but "Annotate Lints" has not. When this happens, click on Annotate Lints to see your problem.
|
||||
|
||||
|
||||
|
||||
You can also see the errors on the "Files Changed" tab of your pull request.
|
||||
|
||||
|
||||
|
||||
Linter failures are usually very easy to fix, and will hopefully be clear from the message alone.
|
||||
|
||||
## Compile Maps / Windows Build
|
||||
|
||||
These two check nothing more than that your code actually compiles, with slightly different requirements. Compile Maps forces all maps (including space ruins etc) to be compiled in, to make sure all of them are valid, and Windows Build makes sure your code actually compiles on Windows. If these tests pass, but other tests fail, it means your code *compiles* but not necessarily that it *works*.
|
||||
|
||||
## Integration Tests
|
||||
|
||||
The real meat and potatoes, this will not only compile the game, but also start a round, and run a bunch of premade tests. If anything runtimes (whether or not it's part of a specific test), there is a bug, and this test will fail. We run this for every station in the game to ensure maximum coverage. If all of these tests fail, your code is almost certainly bugged in some way! Read through the error, and try to resolve the issue. As always, ask maintainers if you need help.
|
||||
|
||||
Sometimes a test will fail on only one map, and not the others. This means two things. The first is, of course, there is a bug on that specific map. This could happen if you, for instance, do a large mapping change, but mess something up only on DeltaStation. The second option is that a flaky test has failed. Not all tests consistently fail/pass, [this is something we actively try to fix](https://github.com/tgstation/tgstation/issues?q=is%3Aopen%20is%3Aissue%20project%3Atgstation%2Ftgstation%2F19). If you believe this has happened to you, you should wait for a maintainer to re-run the failed test.
|
||||
|
||||
## Screenshot Tests
|
||||
|
||||
Screenshot tests exist to make sure things look the same before and after your commit. This helps us detect bugs such as humans not properly rendering clothing/limbs.
|
||||
|
||||
If your commit *does* change the appearance of something saved in a screenshot test, you will automatically receive a message on your PR showing you the before and after. From here, it will contain instructions for how to resolve the issue, whether it's a bug or intentional.
|
||||
|
||||
## Codeowner Reviews
|
||||
|
||||
GitHub comes with a handy feature where we can alert relevant contributors if you edit a file that they are knowledgable with. However, this feature only works with members of the organization. This is inadequate for our purposes, where we encourage contributors to keep an eye on stuff they create.
|
||||
|
||||
Thus, we created our own system that does what GitHub does, but in a way that supports codeowners outside of the organization.
|
||||
|
||||
This isn't a test, but if it fails, it's absolutely not your fault. Contact a maintainer.
|
||||
Reference in New Issue
Block a user