* exwm-workspace.el (exwm-workspace--get-next-workspace): Return
nil when there's only one frame.
(exwm-workspace--on-delete-frame)
(exwm-workspace--remove-frame-as-workspace): Create a workspace
when removing the last one, for X windows to be moved to.
* exwm-workspace.el (exwm-workspace--prompt-delete)
(exwm-workspace--set-desktop): Stop explicitly moving X windows to
other workspace; dealt with by
`exwm-workspace--remove-frame-as-workspace'.
(exwm-workspace--get-remove-frame-next-workspace): Remove
function. Refactored into `exwm-workspace--get-next-workspace'
and `exwm-workspace--remove-frame-as-workspace'.
(exwm-workspace--get-next-workspace): Add function.
(exwm-workspace--remove-frame-as-workspace): Move X windows to
next workspace.
A lot has happened in the meantime (EXWM maintainer change) and this
pulls in all the relevant changes since then.
It may become unnecessary to keep EXWM subtreed, but we'll get to that
later.
Change-Id: I45cc06d747d84b3d28fd0db0e4bb3b749a956583
Sets up the key set and adds an initial secret (besadii config with
tokens) to be deployed to whitby.
Change-Id: Ic07fd5e66b9e7a533013e04c35e052c2aa11f77d
This behaviour was previously confusing, since readTree's data
structure treats children from Nix files and directories as identical
but only one of them would be affected by .skip-subtree
The "subtree" to be skipped here refers to all children of the
structure.
Change-Id: Idf596c9823f09cc2acf49523916bde4b801b8519
Gerrit wraps RFC5322 emails in another layer of quotes when passing
them as flags, and this needs to be unquoted.
Otherwise hook invocations fail with cryptic errors.
Change-Id: Ieeb74c662873d99a4154f8cbc92da77b039cb88e
Ensure that besadii sees $0 as the correct command name, since that is
the sole mechanism by which its functionality is switched around.
There was a lingering commit that introduced this bug and hadn't been
deployed in a couple of days. Maybe time to tighten deploy cycles soon
...
Change-Id: Ie4284c0f6e5e06d71a71a3702ec7e092260e0ce5
Extracts author information from the flags passed by Gerrit and moves
them along to Buildkite. This should display the owners of builds
correctly in the UI, rather than marking everything as coming from me.
Change-Id: If9efe5553a13f0dbdb8bf3936c1d341ae5922318
This is supposedly better for battery health, and since the machine is
usually plugged in while in the office it might be a good idea.
Note for myself: `sudo tlp fullcharge` ~30 min before needing to leave
with a fully charged battery.
Change-Id: I3664264403f56c15e055822190f30c3a90c93ead
Replaces the functionality previously implemented here with the now
generalised implementation in passively.el
Change-Id: Ibe7a1b7d512ddcb700bc330cbdf62811399c6cfe
Adds all the functionality described in the README in cl/4066.
This code is very closely related to //users/tazjin/russian/russian.el
Change-Id: I14f1052cebfbe4886e75e8efc730eacbf8773f29
otherwise we'd return the string "nil", which with the substring-ing
that was happening would end up as "Inbox: i" in the status bar
Change-Id: I567a6042b592dd9313bfa22d480c22936494a8c1
Passively is a tool to help people learn information via Emacs,
designed for language learning.
As of this CL, the actual implementation still lives in
//users/tazjin/russian/russian.el but I am generalising it here.
Change-Id: Iac5a8cfc78415496637a7ba5ddc4c2a1aa6bee26
This makes it possible to use besadii for any TVL-ish setup using
Gerrit and Buildkite, with the same hook functionality as for TVL.
Change-Id: I1144b68d7ec01c4c8e34f7bee4da590f2ff8c53c
Adds configuration keys and rudimentary validation for all other
besadii settings that are currently hardcoded.
This adds the config options:
* repository: Name of the repository in Gerrit.
* branch: Name of the HEAD branch in the repository.
* gerritUrl: Base URL of the Gerrit instance
* gerritUser: Username of the Gerrit user
* gerritPassword: Password of the Gerrit user
* buildkiteOrg: Name of the Buildkite organisation
* buildkiteProject: Name of the pipeline inside the Buildkite
organisation
* buildkiteToken: Auth token for Buildkite access
All of these configuration options are required.
Change-Id: Ie6b109de9cd8484a3773c6351d7fd140f39a49ed
On whitby, the besadii config will live in
/etc/secrets/besadii.json. This CL updates the call sites to pass this
config path to besadii so that it can load Sourcegraph configuration.
Change-Id: Ia139b9fa3b827e7a5f2386214390acc6fe19a75a
Initial step towards moving besadii away from hardcoded values and
onto config files. This is required because I want to reuse besadii
outside of the TVL context.
Change-Id: Id4fa7a49c5d4f876a02b202f04a421ab5ba0dcc4
Change the Nixery configuration to use the plain nixpkgs package path
instead of the depot path. AFAIK, nobody uses this to fetches depot
packages at the moment - but plenty of people fetch non-depot
packages.
This means that Nixery is cache-busted less often (previously on every
commit => every deploy).
We'll figure out another way to have a depot Nixery later.
Change-Id: Iba632333346181c3d2ce992fbab396ed0d9f86aa
... the idea being that this might lead to some people from the Moscow
Nix community to reach out, which would be beneficial for me in terms
of having some IRL people to bounce ideas around with.
Change-Id: Ib41f54609e9ec9d7fdafbf7024fb5df7034afd87
Removes besadii support for the previously used 'ref-updated' hook and
instead introduces support for the 'change-merged' and
'patchset-created' hooks.
These hooks more accurately capture the semantics of when besadii
should trigger CI builds and using them will avoid problems such as
skipping 'canon' builds if chains of CLs are submitted together.
Change-Id: Ib90356c069780bf0c0250e56b927e46a5b31ce7f
This post is intended to just let people know about the existence of
Tvix, tell them a bit about the background and how to follow along.
Change-Id: Ib5194d3aa385a0e30b4768ba28cb063784f6e0a3
Instead of manually tracking the build status through Buildkite
metadata, use the Buildkite GraphQL API in the `🦆` build
step (i.e. the one that determines the status of the entire pipeline
to be reported back to Gerrit) to fetch the number of failed jobs.
This way we have less manual state accounting in the pipeline.
The downside is that the GraphQL query embedded here is a little hard
to read.
Notes:
* This needs an access token for Buildkite. We already have one for
besadii which is also run by the agents, so I've given it GraphQL
permissions and reused it.
* I almost introduced a very rare bug here: My initial intuition was
to simply `exit $FAILED_JOBS` - in the extremely rare case where
`$FAILED_JOBS % 256 = 0` this would mean we would ... fail to fail
the build :)
Change-Id: I61976b11b591d722494d3010a362b544efe2cb25
