It is not actively maintained, third-party, javascript wrapper for GitHub
API. The v7 version has issues and most importantly, we don't need a
JavaScript interface to create a comment. Use the first-party CLI tool
and jq.
Sort artifacts by name while at it.
The value of list options is a table not just for vf and af but for all
object settings lists. Extract just the names from the tables returned
when retrieving these options.
This fixes 2 different bugs:
- mp.add_key_binding('c', ...) taking priority over the builtin g-c
binding.
This follows up 994a08f5a7 which fixed this within the same input
section. This fixes it across different input sections.
- mp.add_key_binding('g-c', ...) not taking priority over a c binding
defined in input.conf.
This happened because is_builtin of bindings added with
mp.add_key_binding is true though they're not actually builtin.
If using --script-opts=stats-vidscale=no, until osd-height changes from
0 to the correct value, stats.lua's text sizes are multiplied by a scale
of 720, which with the default font size results in a font size of 5760.
Depending on the order of operations, if the stats are drawn at this
size before osd-height is updated, mpv freezes. I get this with
--input-commands=script-message-to stats display-stats-toggle in
conditional profiles, e.g.:
mpv --script-opts=stats-vidscale=no --include=<(echo $'[test]\nprofile-cond=true\ninput-commands=script-message-to stats display-stats-toggle') av://lavfi:testsrc
Fix this by setting a scale to 1 until osd-height is updated to the
correct value.
Refine populate_log_with_matches()'s logic to not reserve 2 lines for "n
hidden items" when it is not necessary. This avoids printing "1 hidden
items", and doesn't leave an empty line when there are hidden items only
in one direction.
GitHub cache action doesn't allow updating cache with the same key. We
workaround this by saving the cache with a unique key each time (added
timestamp). This works fine, but since there is a limit on cumulative
storage size for all caches, it can force the master branch cache to be
evicted if a lot of PRs are updated. Cache is evicted with LRU policy,
so as long as master branch cache is used it should stay alive, but it
can happen that only PR specifc caches were only used. As a reminder,
PRs can access the master cache, but they are isolated from each other.
Because of this, it is important to keep the master cache, which is
available to all, alive longer.
The solution is to remove all old caches per branch. This is done in a
separate workflow that validates all cache items and removes ones that
would never be used anyway. If PR is closed all caches per branch are
removed. In other cases most recently used one is preserved.
It is done in a separate workflow to limit cache manipulation access.
GitHub workflows triggered by pull_request event are run in the context
of the fork and does not have access to our token, which is good thing.
Also it is quite awkward to get PR number which triggered build
workflow, so just do a full cleanup pass.
In various edge cases, this causes an assertion that was added later in
8816e1117e to be hit. The actual purpose
of the special case is not really clear. mp_seek already will change the
mpctx->stop_play value, so there shouldn't be any need to do it in
queue_seek. And it is known to cause problems so revert it. Also, remove
the special play direction logic that works around this behavior.
Fixes#13778.
This reverts commit dbdc46c97a.
