feat: allow config file to have config globs by ruocco-l · Pull Request #129 · apify/apify-test-tools

ruocco-l · 2026-09-11T15:24:00Z

Closes #128

New optional configs?: ActorGlobConfigEntry[] on the config file. Each entry is { match, set }: match requires at least one of folder/actorFullName (glob patterns via minimatch), and both can be set together as an AND match (more specific than either alone). set is required — a match with nothing to apply is a misconfiguration and readConfigFile throws.
The merge is field-agnostic — set overlays whatever properties it carries with no special knowledge of tokenEnvVar or any other field name. An unrecognized/misspelled property merges in and simply has no effect, same as today.
Precedence, lowest to highest: matching folder-only entries → matching actorFullName-only entries → matching combined (folder AND actorFullName) entries → the actor's own literal entry (never overridden). Within a single tier, only the last matching entry (array position, not pattern specificity) applies — earlier same-tier matches are dropped outright, not merged in.
Across tiers, results deep-merge instead of shallow-overwriting: a higher tier wins on any field it sets, but a field it doesn't set is inherited from a lower tier rather than being lost. Nested objects merge key by key (so a future field like notifier: { slack: {...}, email: {...} } can be filled in piecemeal across tiers instead of one config entry clobbering the whole object), and array fields (e.g. overrideActorContext) keep the higher tier's array intact and append only the lower tier's genuinely novel entries, preserving the higher tier's order. This is backed by a new hand-rolled, unit-tested deepMerge helper.
Matching follows standard minimatch glob rules, see https://github.com/isaacs/minimatch for the full pattern syntax. Notably, "match every actor" needs **, not *, since * doesn't cross path segments.
tokenEnvVar is optional on an actor entry now, but still required overall: once an actor's full config is resolved (literal + any matching configs), a tokenEnvVar must be present or readConfigFile throws — this is the only place the code cares about that specific field name. This is a design choice and should be work as example. Merging the globs doesn't assume anything about the structure of the ending result of the config file, check on the correct shape of the actor configuration must be placed after the globs merge.
configs is entirely optional; a config file without it behaves exactly as before.
Types: ActorIdentity (folder/actorFullName) and ActorSettings (tokenEnvVar/overrideActorContext) are now shared building blocks — an actors[] entry is ActorDeclaration = ActorIdentity & ActorSettings, and the resolved output ActorConfig extends ActorIdentity, so the two can't silently drift apart. The top-level config file shape is renamed ConfigFileSchema (previously ActorConfigFile, which read too similarly to the unrelated ActorConfig).

metalwarrior665

This looks simpler than I thought :) I have just minor remarks, feel free to argue against them. Let's wait for Juan but this seems quite uncontroversial.

metalwarrior665 · 2026-09-12T10:04:37Z

+    for (const [index, configEntry] of configs.entries()) {
+        const { folder, actorFullName } = configEntry as ActorGlobConfigEntry;
+
+        // TODO: Allow for combined filtering?


I would allow this, don't think it is that confusing or dangerous. You simply filter once per folder and then per name. There might be legit use-cases for this

metalwarrior665 · 2026-09-12T10:08:59Z

 import { selectActors } from './actor-filtering.js';
 import { isPathWithinScope } from './path-utils.js';
-import type { ActorConfig, ActorConfigFile } from './types.js';
+import type { ActorConfig, ActorConfigFile, ActorConfigFileEntry, ActorGlobConfigEntry } from './types.js';


These types don't match very well, one says "File", other doesn't.

btw we already have ActorConfig type which is basically the same thing, we should either unify them or derive one from the other. Are there cases where these will differ? If we are simply merging them then they should not differ. No need to solve that in this PR but sooner rather than later.

metalwarrior665 · 2026-09-12T10:13:35Z


+const validateGlobConfigEntries = (configs: unknown[]): ActorGlobConfigEntry[] => {
+    for (const [index, configEntry] of configs.entries()) {
+        const { folder, actorFullName } = configEntry as ActorGlobConfigEntry;


Could be zod parse I guess but I don't know if you can get such a nice errors from it, don't have experience

I also don't have much experience with zod but when I looked into it I remember that there was a lot of overhead to make it work. I don't think it's necessary, as long as the inputs here are somewhat limited in number

metalwarrior665 · 2026-09-12T15:21:10Z

+
+    let overlay: Partial<ActorConfigFileEntry> = {};
+    for (const configEntry of [...matchingFolderConfigs, ...matchingActorFullNameConfigs]) {
+        const { folder: matchedFolder, actorFullName: matchedActorFullName, ...rest } = configEntry;


Let's think a bit if we shouldn't separate the matching fields folder, actorFullName vs the configs, it is a bit weird they are on the same level

metalwarrior665 · 2026-09-12T15:22:57Z

+    );
+
+    let overlay: Partial<ActorConfigFileEntry> = {};
+    for (const configEntry of [...matchingFolderConfigs, ...matchingActorFullNameConfigs]) {


If we want to support having both folder and name with AND logic, this would need to change

metalwarrior665 · 2026-09-12T15:23:57Z

+    const matchingActorFullNameConfigs = configs.filter(
+        (configEntry) =>
+            configEntry.actorFullName !== undefined &&
+            typeof actorEntry.actorFullName === 'string' &&


We already validate this eariler and the type should be string | undefined now, no?

332a437
We didn't, but now we do

ruocco-l · 2026-09-13T14:17:07Z

In this PR I postponed the problem that would pose adding the notifier object. As of now, an object would be completely rewritten and it does not have a partial merging logic (e.g. every notifier would get the same token but each actor needs to get its own slack channel for test report). I gave it some thought and even though it's not necessary as of this PR would be merged, we want to add it soon so it makes sense to do it here, so that the diff is tidy.

@metalwarrior665 I'll do your requested changes first and then I'll try to add the deep object merging logic.
@JuanGalilea I'll make this PR a draft until it's ready with the changes I mentioned above, I'll ping you when it's ready to review again.

…iers

metalwarrior665 · 2026-09-14T22:09:24Z

+1. entries matching on `folder` alone
+2. entries matching on `actorFullName` alone
+3. entries matching on both `folder` and `actorFullName` together


This might be more complicated than just order based

metalwarrior665 · 2026-09-14T22:11:51Z

 const validateGlobConfigEntries = (configs: unknown[]): ActorGlobConfigEntry[] => {
    for (const [index, configEntry] of configs.entries()) {
-        const { folder, actorFullName } = configEntry as ActorGlobConfigEntry;
+        const { match, set } = configEntry as ActorGlobConfigEntry;


I would give this 2nd thought; maybe it is unnecessarily nested now just for the 2 matcher fields.

metalwarrior665 · 2026-09-14T22:23:33Z

+3. entries matching on both `folder` and `actorFullName` together
+4. the actor's own literal entry in `actors[]`
+
+Within a single tier, if more than one entry matches, only the _last_ one (array order) applies — earlier same-tier matches are dropped entirely, not merged in. Across tiers, results are deep-merged from lowest to highest precedence: a higher tier wins on any field it sets, but a field it doesn't set is inherited from a lower tier rather than being lost. Object-valued fields merge key by key; array-valued fields (e.g. `overrideActorContext`) keep the higher tier's array intact and append only the lower tier's entries that aren't already present, preserving the higher tier's order.


This is too complex. I would drop the notion of tiers completely. 1-3 can just be taken in order (any use-case for the current way?). And the point 4 can stay undocumented (for backward compat) and we just append it at the end of the glob array so it will override any conflicting fields before.

only the last one (array order) applies — earlier same-tier matches are dropped entirely, not merged in

I don't get this. I thought the whole goal is to merge here. E.g. one glob sets token on Actor X, another glob sets slack on Actor X etc., these are merged in the config object. Theoretically, we could only merge the top level config fields but I'm not sure about this

array-valued fields (e.g. overrideActorContext) keep the higher tier's array intact

I think we should not merge arrays. They shouldn't include more nested objects so there won't be need for any deep merging. Users can just retype the whole array in the later glob.

feat: allow config file to have config globs

8f4c960

ruocco-l requested a review from JuanGalilea September 11, 2026 15:24

ruocco-l requested a review from metalwarrior665 as a code owner September 11, 2026 15:24

metalwarrior665 requested changes Sep 12, 2026

View reviewed changes

ruocco-l marked this pull request as draft September 13, 2026 14:17

ruocco-l added 4 commits September 14, 2026 11:16

add deep merge utility

695a71e

apply configs with tiered precedence and deep merge across matching t…

0047dda

…iers

update readme

db6db6e

logically pair check on folder and actorFullName

332a437

ruocco-l requested a review from metalwarrior665 September 14, 2026 12:11

ruocco-l marked this pull request as ready for review September 14, 2026 12:35

metalwarrior665 requested changes Sep 14, 2026

View reviewed changes

metalwarrior665 mentioned this pull request Sep 14, 2026

Feat/read actor json #135

Open

3 tasks

Navigation Menu

Uh oh!

feat: allow config file to have config globs - #129

feat: allow config file to have config globs#129
ruocco-l wants to merge 5 commits into
masterfrom
feat/config-globs

ruocco-l commented Sep 11, 2026 •

edited

Loading

Uh oh!

metalwarrior665 left a comment

Uh oh!

metalwarrior665 Sep 12, 2026

Uh oh!

metalwarrior665 Sep 12, 2026

Uh oh!

metalwarrior665 Sep 12, 2026

Uh oh!

ruocco-l Sep 14, 2026

Uh oh!

metalwarrior665 Sep 12, 2026

Uh oh!

metalwarrior665 Sep 12, 2026

Uh oh!

metalwarrior665 Sep 12, 2026

Uh oh!

ruocco-l Sep 14, 2026

Uh oh!

ruocco-l commented Sep 13, 2026

Uh oh!

metalwarrior665 Sep 14, 2026

Uh oh!

metalwarrior665 Sep 14, 2026

Uh oh!

metalwarrior665 Sep 14, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Uh oh!

Conversation

ruocco-l commented Sep 11, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

metalwarrior665 left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ruocco-l commented Sep 13, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

ruocco-l commented Sep 11, 2026 •

edited

Loading