The generate-docs action previously always required secrets to run so
that it could possibly perform a push (if run from a schedule), and to
send out an email on failure. Since secrets are unavailable for forks
this meant that this action would always fail for PRs from forks.
In this patch we use an unauthenticated clone unless running from a
schedule. This is fine as for PRs this action would just regenerate the
docs to check for errors, but not to actually update them (no push
performed). We also change the failure notification step to only execute
for scheduled runs.
* topic/christian/management-print-cmd:
Management framework: bump external testsuite
Management framework: allow selecting cluster nodes in get_id_value
Management framework: minor tweaks to logging component
Management framework: bump zeek-client to pull in get-id-value command
Avoid whitespace around function type strings in JSON rendering
Management framework: improve handling of node run states
Management framework: add get_id_value dispatch
Management framework: allow dispatching "actions" on cluster nodes.
Management framework: some renaming to avoid the term "data cluster"
Management framework: allow agents to communicate with cluster nodes
This adds an optional set of cluster node names to narrow the querying to. It
similarly expands the dispatch mechanism, since it likely most sense for any
such request to apply only to a subset of nodes.
Requests for invalid nodes trigger Response records in error state.
Callable types were rendered with a trailing "\n" in to_json() output. Tweaking
the Describe() calls to stop producing the newline is prone to test failures, so
this focuses on the JSON string production to suppress it, which doesn't affect
any tests.
When agents receive a configuration, we don't currently honor requested run
states (there's no such thing as registering a node but not running it, for
example). To reflect this, we now start off nodes in state PENDING as we
launch them via the Supervisor, and move them to RUNNING when they check
in with us via Management::Node::API::notify_node_hello.
This adds support for retrieving the value of a global identifier from any
subset of cluster nodes. It relies on the lookup_ID() BiF to retrieve the val,
and to_json() to render the value to an easily parsed string. Ideally we'd send
the val directly, but this hits several roadblocks, including the fact that
Broker won't serialize arbitrary values.
This adds request/response event pairs to enable the controller to dispatch
"actions" (pre-implemented Zeek script actions) on subsets of Zeek cluster nodes
and collect the results. Using generic events to carry multiple such "run X on
the nodes" scenarios simplifies adding these in the future.
This provides Broker-level plumbing that allows agents to reach out to their
managed Zeek nodes and collect responses.
As a first event, it establishes Management::Node::API::notify_agent_hello,
to notify the agent when the cluster node is ready to communicate.
Also a bit of comment rewording to replace use of "data cluster" with simply
"cluster", to avoid ambiguity with data nodes in SumStats, and expansion of
test-all-policy.zeek and related/dependent tests, since we're introducing new
scripts.
* origin/topic/robin/gh-2032-dict-fixes:
Add tests exercising dictionary iteration during modification.
Fix another crash during dictionary iteration.
Fix assertions in dictionary that can trigger for benign reasons.
Fix robust iterators when modifying dictionary during iteration.
These assertions were checking for a situation that I believe can
happen legitimately: a robust iterator pointing to an index that,
after some table resizing, happens to be inside the overflow area and
hence empty. We'll now move it to the end of the table in the case.
When inserting/deleting elements, we now remove their `DictEntries`
from any robust iterators' bookkeeping. First, we don't need that
information anymore, and second the `DictEntries` contain pointers
that may become invalid.
I don't know how to write a unit test for this unfortunately because
it depends on where exactly things land in the hash table.
Btw, memory mgmt for DictEntries is pretty fragile: They contain
pointers to both memory they own (`key`) and memory they don't own
(`value`). The former type of pointers is shallow-copied on
assignment/copy-construction, meaning that there can be multiple
instances seemingly owning the same memory. That only works because
deletion is manual, and not part of standard destruction. The second
type of pointer has a similar problem, except that it's managed
externally. It's important to not end up with multiple `DictEntries`
pointing to the same value (which is actually what that iterator
bookkeeping did).
Addresses #2032.
#1835 subtly changed the semantics of the `LoadFile` plugin hook to no
longer have the current script location available for signature files
being loaded through `@load-sigs`. This was undocumented behavior, so
it's technically not a regression, but since at least one external
plugin is depending on it, this change restores the old behavior.
We could already pass an overriding tag to
`Analyzer::AnalyzerConfirmation()`, but we didn't have that ability
for `AnalyzerViolation`, leading to the two potentially mismatching in
the analyzer they report.
