feat: capture files with time-based variables for job attachments

[epmog]

Resolves #125

What was the problem/requirement? (What/Why)

The deadliine-cloud rop node was evaluating parms at the current frame. So any filepaths that contained time-based variables would only have 1 of those files captured rather than the whole sequence

What was the solution? (How)

There were a few solutions available, each with various downsides.

1. Evaluate the parm with evalAsStringAtFrame`, would require us to figure out all the relevant frame numbers and adjust for offsets.

   • this requires us to get it perfectly correct - which is definitely higher effort

2. Grab the directory before the frame variable

   • anecdotal evidence seems to indicate frames are mostly in the file name, but users are not restricted to having them in directories. So automatically uploading whole directories without insight as to why they're added leads to the potential of a lot of extraneous files uploaded.

3. Replace the relevant variables with globs and and let the stdlib take care of finding them.

I went with replacing the time-based variables for input filenames with globs to allow us to do some naive pattern matching. The code itself is then pretty simple with avenues to improve it later.

• Downside here is there may be inadvertent files that get included because they match the glob pattern and not the time variable. Future improvement could be to filter out files that matched the globs but not the pattern
• Input directories are being ignored in this change, since the solution can be equivalent to going up a directory, which can be pretty dangerous while multiple levels of directories down from frames seem like a pretty rare case.

What is the impact of this change?

We get a LOT more of the files users want to be included with the job!

How was this change tested?

Added a bunch of unit tests to capture the pattern replacement and globbing functionality.

hatch run fmt
hatch build
hatch run lint
hatch run test

Test coverage is now at ~67%

Required test coverage of 65.0% reached. Total coverage: 67.59%

I'll need to retest the node within Houdini again after some rebasing.

Was this change documented?

N/A

Is this a breaking change?

Fixing!

---

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
No data about Coverage
0.0% Duplication on New Code

See analysis details on SonarCloud