Quietens Spaceman when debugging UNIT_TESTS locally (#75570)
The contract is removed by virtue of testing.
Co-authored-by: Jordan Dominion <Cyberboss@users.noreply.github.com>
## About The Pull Request
Bumps the emoji remover action's commit hash +1 to [the current
one](de0c1d158e)
which has passed my node16 testing.
Necessary for when github intends to disable node12 later this year.
## Why It's Good For The Repo
Paying off some tech debt so the action continues to help maintain
maintainer sanity into 2024 and byond,
## Changelog
Non player/admin facing change.
Co-authored-by: Wayland-Smithy <64715958+Wayland-Smithy@users.noreply.github.com>
Co-authored-by: lessthanthree <83487515+lessthnthree@users.noreply.github.com>
## About The Pull Request
Hey there,
It's on the tin, we just cache the whole Rust installation to use over
multiple workflows. Without this, it would take up to _five minutes per
linters workflow run_ to install the whole fucking rust toolchain/crate
dependencies (ref:
https://github.com/san7890/bruhstation/actions/runs/3536980337/jobs/5936542571
).
Now with the cache, it's now down to approximately one minute, thirty
seconds after it's able to pull a cached rust installation (ref:
https://github.com/san7890/bruhstation/actions/runs/3537002138/jobs/5936585526
). More than half is very good, and frees up valuable Github Runners
slots sooner!
I've also always seen linters as that rapid check to immediately call
you out whenever you screw up in a PR, and it taking four minutes sorta
lessens that immediate: "HEY, LISTEN!" aspect
Co-authored-by: san7890 <the@san7890.com>
Probably lets us use merge queue. I would be doing this on a fork but I
don't have access to the beta 🤷♀️
Pull request for the sake of downstreams but I intend on self merging
this (and my followup test PRs, though to another branch). Will start
with commit queue on my project branch.
Should be noted that I predict flaky tests might hit us harder, since it
might stop the entire queue? I'll see
Co-authored-by: Mothblocks <35135081+Mothblocks@users.noreply.github.com>
* Adds CI check to detect if byond starts requiring 515 clients before we want that (#74364)
todo: (i'm going to bed or i'd do them before opening the pr)
fork the action over to the org
~~make this more configurable as mothblocks requested~~
~~add this to the windows build and integration test steps (if it
generates a dmb, we gonna validate its got the expected value for client
compatibility)~~
~~test 515 client required fails.~~
https://github.com/MrStonedOne/byond-client-compatibility-check
---------
Co-authored-by: Mothblocks <35135081+Mothblocks@users.noreply.github.com>
* Client Compatibility Check Actually Uses Our Fork (#74514)
## About The Pull Request
In #74364 (e0ac161029), we wanted to use
the fork for this action rather than MSO's version. However, we only
updated the changeover to the `tgstation` version in one location, not
all occurrences in our CI suite.
This PR cleans that up real fast.
---------
Co-authored-by: Kyle Spier-Swenson <kyleshome@gmail.com>
Co-authored-by: Mothblocks <35135081+Mothblocks@users.noreply.github.com>
Co-authored-by: san7890 <the@san7890.com>
Maplint tool now has proper github action error messages (#72920)
## About The Pull Request
The tool added in #72372 is pretty awesome. The output is uhh cryptic
though. I had to read the source code to realize the (line 382) or
whatever part of the message was the dmm line number and there's stack
traces everywhere. I've made it support github action error messages so
now you get this beauty if you mess up:
Or, in the run summary:
Errors parsing the lint yml's will also output github action errors,
although the line number will always be 1 since the yaml parser discards
line numbers to my knowledge.
In the midst of doing this, I made the error type contain the file and
line info, and added a bunch of type hints in the midst of trying to
understand Mothblock's code.
Note that for power users, the default behavior is still colored
terminal text; `--github` is added by the CI suite to enable this
behavior.
## Why It's Good For The Game
Much easier to see where the errors are and what they are (who even
knows what a 'pop' is? The tg game code calls them grid models.)
## Changelog
Nothing player-facing.
* Replace nearly every map grep with a YML file that actually respects structure, and fixes the massive amount of failures that were never caught (#72372)
[Documentation
here](https://github.com/Mothblocks/tgstation/blob/maplint/tools/maplint/README.md)
We should not be using greps to the capacity that we currently are. If
you are not smarter than a parser, then you should not try to beat one.
DMM files should NOT be treated as text files that can be parsed with
any old Unix tool. They are a structured language. Because of our abuse
of greps, check_greps is full of hard to read, hard to maintain checks
that do not consistently work, because they all make very specific
assumptions about how TGM works, which are provably untrue.
This format is mostly straightforward for the lints people write, and
easily extensible to the ones people will want to write.
🆑
fix: Fixes a bunch of cases of windows not being where they were
supposed to be, tables/chairs stacking on each other, and other very
small stuff you've never noticed before.
/🆑
* pointless line change
* desync
* bye
Co-authored-by: Mothblocks <35135081+Mothblocks@users.noreply.github.com>
Co-authored-by: Paxilmaniac <paxilmaniac@gmail.com>
Run CI, merge conflict checks, and 515 compat on "project branches" (#71601)
## About The Pull Request
Here introduces "project" branches. Branches designed for bit by bit
contributions of large scale refactors and changes. PRs to these
branches will show up on tracker like normal but won't apply to master
until the project branch itself is done and merged in. This allows for
much easier review and atomization without compromising master with
temporary hacky code.
A maintainer will create a project branch on the repository, allowing
any contributor to PR to it like normal. Very simple.
An example of this use can be seen in the basic bots PR. It is too large
to be full sent as one PR, but doing it one bot at a time will result in
a lot of bugs and copy and pasted code. This way, we can update bots one
by one until they're all done, then full send it.
This PR adjusts our CI (as well as merge conflict checks and 515
compatibility) to run on "`project/`" branches in addition to master.
Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com>
Rerun flaky tests automatically, and create issue reports for them (#71519)
Adds a new workflow that will try to automatically detect and rerun
flaky tests, and create an issue report for them.
The detection mechanism is heuristic: if exactly ONE job fails in the CI
Suite, then it is assumed to be flaky, and will be rerun. If the next
run succeeds, then it will create an issue report for that flaky test if
one does not already exist. It will do its best to create a unique but
consistent identifier, aided by PRs like #71515. You can find an example
here: https://github.com/Mothblocks/ss13-workflow-testing/issues/20.
Maintainers can also rename the issue if they wish, it will still be
able to find it.
While there is a chance for this mechanism to go wrong and create bogus
issue reports, it IS possible to easily disable actions, I did it for
the stale one just a bit ago. Most likely, this mechanism going wrong is
going to be the result of randomness leaking in tests, like random human
names, so this can be solved in the tests themselves. I find it
extremely unlikely, but in the worst case scenario where this happens
often, we can add a way for maintainers to edit the issue report and
include a regex to match for runtimes. Just an idea.
Includes a few large-ish downloaded logs from past failures that are
interesting in unique ways. These are used for tests of the title
generator.
Co-authored-by: Mothblocks <35135081+Mothblocks@users.noreply.github.com>
