This repository has been archived by the owner on May 14, 2024. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 12
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Merge branch 'master' of https://github.com/tgstation/tgstation
- Loading branch information
Showing
8,616 changed files
with
1,597,566 additions
and
849,866 deletions.
The diff you're trying to view is too large. We only load the first 3000 changed files.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,9 @@ | ||
| # This file contains extra tests to run for specific BYOND versions. | ||
| # This is useful for making sure we maintain compatibility with both older and newer versions, | ||
| # while still having our main tests run on a guaranteed pinned version. | ||
|
|
||
| # Format is version: map | ||
| # Example: | ||
| # 500.1337: runtimestation | ||
|
|
||
| 515.1603: runtimestation |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,17 @@ | ||
| # Atomization (AKA, splitting up pull requests) | ||
|
|
||
| Maintainers are volunteers and have limited time to review pull requests. Large pull requests can be hard to review. You can help us help you by splitting your PR up into more manageable chunks. | ||
|
|
||
| ## Keep it on topic | ||
|
|
||
| A pull request for changing the color of airlocks should not also change the damage for guns. | ||
|
|
||
| In general, keep balance PRs separate from fix/refactor PRs, unless there is a reasonable explanation for having them in the same pull request. For example, if in your PR for changing airlock colors, you clean up the code to improve variable names in airlock code, that is completely fine to keep in the same pull request. Fixes are something we can merge if the code looks right. Balance changes/new features are something we can only merge once we evaluate design concerns, which is much slower. | ||
|
|
||
| ## Split it up if it's big | ||
|
|
||
| Sometimes a refactor might end up being a lot larger than you expect, and suddenly it is very hard for us to review, even though it's all on topic. | ||
|
|
||
| We encourage contributors to, when reasonable, split up huge refactors into several chunks, or to split them off from your features entirely. It is even okay to make a small pull request to add an easy to review API even if the code is unused, just be up front about the changes you are planning to make. These pull requests will be tagged with the "Atomic" label. Every so often, maintainers might look at past PRs with this label and remove the code if it is still unused, or if you have let us know you don't plan on finishing it (though in this case, please remove it yourself). When you should do this isn't written in stone; if adding a consumer of the API is just a matter of a few lines, then you should just do that. On the other hand, if adding this API requires touching a lot of existing code, and would be hard to remove if you don't finish, you may be asked to put it in the PR that adds the consumers. | ||
|
|
||
| This does not necessarily apply to features/balance changes. We don't want half of a feature implemented because it leaves you and us uncertain to if the followup pull requests are going to be merged. For example, do not add a new item to the game that goes completely unused until a separate pull request which decides where it's going to go. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -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. |
Oops, something went wrong.