| Age | Commit message (Collapse) | Author |
|---|
|
serenity and matrix-sdk pull in quite a lot of dependencies, which for a
minimal use of ezau might not be wanted. Therefore, we now disable those
parts by default, and the user has to opt-in into building ezau with
Discord or Matrix functionality.
|
|
Those functions are not used anywhere else and just produce dead code
warnings.
|
|
|
|
Equipped with the LogBag, we can now rework the "madness" that is the
Discord `find_insertion` thing, even though it wasn't all too bad (and
probably faster than the current version).
|
|
Doing all the "new log" insertion based on simple string operations is a
bit of madness, so the proper course of action is to parse them into a
proper intermediate representation from which we can then generate a
plain and HTML body.
In addition, this has some other minor code cleanup for the matrix
module.
|
|
|
|
Similar to Discord posting, this now allows ezau to post a message to
the given Matrix room for every log.
The text handling is still pretty bad and should be reworked, but so
should the Discord one. This is just the initial support, now that the
actual posting works we can add some tests and proper text parsing,
together with unifying some of the logic between Discord and Matrix.
Note that this currently only works for unencrypted rooms!
|
|
This is a bit bigger than usual, because it brings the serenity update
from 0.8.x to 0.9 with a lot of API changes. The biggest offender is the
new async environment, which means that we need to sprinkle some .awaits
here and there, as well as use tokio to spawn a runtime. Serenity
currently uses tokio 0.2, so we need to stick to the older version until
serenity updates, otherwise we'll get a runtime mismatch.
Another small change comes from serenity switching to typemap_rev[1]
instead of their old implementation, which is currently still missing
some methods. Until those are implemented[2], we're patching the
dependency directly.
The good news is that all of the changes are pretty much contained to
src/discord.rs only, as the other parts of ezau could stay untouched.
[1]: https://github.com/bdashore3/typemap_rev
[2]: https://github.com/bdashore3/typemap_rev/pull/1
|
|
There's a good chance that this version of evtclib will stay as 0.5, so
it's a good idea to adapt our code to the API changes (mainly using
evtclib::Encounter instead of evtclib::Boss).
|
|
|
|
The CM detection in evtclib has been fixed in 0.4.3 so we can now rely
on that again.
|
|
100/99 have been moved to 99/98.
Due to broken CM detection on Skorvald, the check has been hacked
together for now until a proper CM detection is working again.
|
|
|
|
This is way more accurate than Log::was_rewarded, especially for
repeated kills in a week.
|
|
If you use ezau on Windows, you might prefer to use the built-in zipping
functionality from arcDPS instead of relying on ezau to do this job.
However, that would lead to weird interactions because arcDPS would
still create the temporary file in the watched folder, and
powershell would race with ezau to zip and delete this temporary file.
To prevent this from breaking existing (& working) configurations - and
to stick true to the name - zipping is enabled by default if not given
otherwise in the configuration.
|
|
If we don't do this, we end up trying to decode the error page as the
expected JSON response, which usually ends up with a "missing permalink"
field, which doesn't tell us a lot.
This way, we get a proper 404/500 error.
|
|
As it turns out, uploading is often the reason why the process
crashes/exits. This is bad because it means that 1) we lose links to
logs (as they are not being uploaded), leading to incomplete reporting
and 2) we rely on an external watchdog to keep the service alive (and
I'd rather just not have ezau crashing, especially on Windows where we
usually don't supervise it with systemd).
Therefore, a configuration setting has been added that lets ezau retry
the upload process. This is not 100% good and failsafe, because
1) it always waits a hardcoded amount of seconds (instead of e.g. using
a proper backoff timer)
2) it blocks the rest of the process, so no logs will be compressed
while it is retrying a single log
3) after those retries, the process will still exit
But it is a good first approximation, and the aforementioned issues can
be fixed "relatively easily" (e.g. by moving the whole per-log logic
into a separate thread(pool) and handling failures even better).
|
|
This will ensure that ezau will post a new message if editing the old
one would push it above the character limit.
|
|
Some error messages currently look very weird. For example, if the given
configuration file does not exist, it gives you an error about a missing
file - which could also be the file to upload though, as the error
doesn't specify. Therefore, some more context for the error messages is
nice.
The "sourceback" could still use some work.
|
|
This makes discord::post_link return any Error (or well, Result) that is
produced by the ready event handler.
|
|
This is important to signal e.g. systemd that there was an error and the
process should be restarted.
|
|
This might help with identifying in the logs when/if ezau was started,
and when the control flow returned from the Discord client to ezau.
|
|
|
|
The other one was hard to see, as it was rendered as a darkgrey
checkmark on grey background.
|
|
ezau having the watching functionality is nice, but sometimes for
scripts you might want to have the old "upload this single log and post
it to discord" functionality. As such, ezau has now been split into two
subcommands (which use the same core):
ezau watch runs the inotify-based directory watcher to zip and upload
new logs. Additionally, it now respects the "upload = ..." config
settings, which means you can also use it as a zipper only, without
having every log uploaded.
ezau upload performs a single-shot upload with the discord notification.
Furthermore, the discord auth token/channel id have been moved to a
configuration file. Switches to override this for single runs might be
provided in the future, but for now, it seems more sensible to have it
in a persistent configuration.
|
|
evtc-watch consists of three parts at the moment: watch the files, zip
them up and call ezau to upload them. We can now just do all of those
inside of ezau, which saves us the extra script, makes it more
platform-independent (as notify also works on Windows) and makes
configuration and everything easier, as all the data will be inside of
one program and doesn't need to be passed around.
A flag (or subcommand!) to upload a single file might be added later to
retain the previous behaviour of ezau.
|
|
|
