1,140,793 events, 664,996 push events, 998,041 commit messages, 76,418,086 characters
fuck you snow
Signed-off-by: Tamaized [email protected]
app bar: Fix height, especially when no back button
These app bars -- all our app bars outside the message list, which uses ChatNavBar -- didn't have anything to actually specify how tall they should be.
When the back button is present, it serves as a strut to keep the app
bar at least as tall as the button is, which gets us pretty close:
just a fraction of a pixel off in my testing on an Android 11
emulator. (In fact I don't understand why it isn't exactly right:
NavButtonGeneral sets the height to NAVBAR_SIZE.)
But when the back button is not present, the app bar would collapse to the height of the text, which is typically much shorter.
Fix both cases by simply specifying the intended height, as a minimum.
We actually used to have explicit heights like these, as simply
height: NAVBAR_SIZE, and removed them a little while ago in #4443
in commits 635b13a39 and a9ab3fc21. The stated reason was to better
handle large font sizes; it also simplified rearranging things for
getting these SafeAreaViews in place. But those have settled down,
and by using minHeight there's no trouble if the user has a very
large font-size setting. (Also I don't think we noticed at the time
that this had a large visible effect in the no-back-button case; if
we had, we'd have done something about it then.)
In the case of ChatNavBar, we do specify the height, and ideally
we'd say minHeight instead there too. But that causes hilariously
wrong results, presumably due to a bug somewhere else in our layout.
For the present, just leave a TODO comment there.
[MIRROR] Removes dead code in techwebs, alongside some truly evil macros [MDB IGNORE] (#8652)
- Removes dead code in techwebs, alongside some truly evil macros (#61936)
fuck you kevin
- Removes dead code in techwebs, alongside some truly evil macros
Co-authored-by: LemonInTheDark [email protected]
Add nightly tests for supported K8s versions (#759)
We need to ensure that we're testing all of the supported versions of Kubernetes. As APIs are upgraded/removed we should not rely on manually verifying which APIs are being used and which are still valid.
I've added a smoke test here which stands up a kind cluster (for each supported version), deploys the operator, and runs the bank workload for a few seconds just to ensure things are working.
You might be thinking, "why not just run (one of) our e2e tests?" The
answer is that I wanted to ensure we had a test in place that does what
our docs tell users to do. Which is to install the crds from
install/crds.yaml, the operator from install/operator.yaml, and the
example from examples/example.yaml. These files are updated whenever
we do a release or run make release/gen-templates.
To make sure the cluster is functional, the test also adds the secure client pod and executes the bank workload for 10s.
Finally, I've added a new GitHub workflow to run these tests nightly. I chose 3am rather arbitrarily since I figured almost everyone else chooses midnight 😄
Redoes lense code , Thermal lenses no longer provide night vision. (#6607)
-
initial fuckeryh
-
horrible deeds
-
removes explosive lenses and fix grammar
-
Update stealthy and inconspicuous weapons.dm
Co-authored-by: MLGTASTICa [email protected]