Test2::Plugin::GitHub::Actions::AnnotateFailedTest Annotate failed tests with GitHub Actions workflow command
This is a Test2 plugin that provides annotations for failed tests running in GitHub Actions workflow, using a workflow command.
You can use it with
use Test2::Plugin::GitHub::Actions::AnnotateFailedTest regardless of running in GitHub Actions workflow or not.
- Is the name appropriate?
- Can I publish it to CPAN from current master branch and install successfully? (Are the dependencies enough?)
Linux::Input::Capabilities Read /sys to determine the event types attached input devices can emit
This is a module for parsing
/sys/class/input/input*/capabilities/* which is a Linux-specific interface. Linux exports all the events that the device can report, separated into several categories (some stretching belief in calling them input devices, like the PC speaker — but that's what Linux does). Linux unfortunately exports these as bit strings, encoded in hex, split in to words without leading zeros. And yes, word length does vary by architecture.
The modules already include POD. And some tests, too.
The …::Constants module is auto-generated from the Linux C headers by InputCapsFromHeader.pm. Which isn't a NIH re-implementation of
h2xs, I'm pretty sure.
Modules in the neighborhood I'm aware of:
Linux::Input, which I believe is mainly for getting the events from the devices and looks like it requires permission to actually open the devices. (I don't think I'm stepping on its namespace, as there are already multiple modules under
Linux::Input::by different authors).
Linux::Input::Info— reads the easy files, does not do capabilities. Possibly my module could be merged into this, but last update of 2008 doesn't give me much hope. Also, this appears to be opening the device in
/dev, not using
The synopsis, tested on a VM, spits out:
Input devices found (numbers): 0, 4, 2, 3, 5 Input device found: input0, AT Translated Set 2 keyboard Input device found: input4, Power Button Input device found: input2, ImExPS/2 Generic Explorer Mouse Input device found: input3, QEMU QEMU USB Tablet Input device found: input5, PC Speaker Device AT Translated Set 2 keyboard answers questions
BTW: This is currently part of an application I'm writing, App::ABAN, and currently it lives in the same repository. I'm thinking I'll move it to its own, or at least build it separately, once its ready for CPAN. (My PAUSE ID hasn't be processed yet, so I've been working on other things).
Rex::Hook::File::Diff Show diff of file changes during a Rex run
The linked gist is the initial draft of a module that allows Rex to show diffs on the terminal upon file changes during task execution. I'm posting it here both for early availability and early feedback.
I think it is a good example of how to extend Rex without changing the core, and publishing on CPAN would be a great way to share.
Additional features could include colored output support, and pluggable diff backends (like Text::Diff::Unified::XS, or even using
diff binary, if present).
The name is following this logic: it extends
Rex via a
File operations to show the
Diff of changes. It could be more specific (e.g.
Rex::Hook::File::Diff::Unified), but I feel it's already getting long, so I tried to find a good balance.
Some questions I am wondering about:
- is there a better fit for the name?
- would it be possible/easy to merge this into Rex core distribution later (which already has
- is there a better approach to generate diffs?
Feedback welcome both here and on the gist.
Mojo::Promise::Limitter limit outstanding calls to Mojo::Promise
I'm currently playing with async-await in Mojolicious. It's great.
When I want to call a lot of external commands, I noticed that there is no way to limit concurrent calls to external commands. So I tried creating Mojo::Promise::Limitter.
- Is there already a module that has the same functionality as this module?
- Any feedback (including implementation) is welcome.
Net::DNS::DomainController::Discovery Discover Microsoft Active Directory domain controllers via DNS
This simple module should enumerate all domain controllers via DNS SRV records.
I have a problem to find a proper name - Net::DNS::ActiveDirectory::DomainController::Discovery is way too long.
Any better ideas?
Regex::Wrapper OO Perl Regex Wrapper
Just running this by everyone and wondering what is thought...
It's a small, 2-file collection OO wrapper providing Perl Regex functionality. Matching, substitution, to/from matching index info, etc. are available.
Regex::Wrapper and Regex::Wrapper::Match are the package names.
The code in the 'Synopsis' section closest to the bottom is some 'driver' code that exercises the packages.
Thanks to anyone who takes the time to check this out.
MooX::TwoWayAttribute Allow attributes to know who owns them
This dist would consist of two modules
MooX::TwoWayRelations - adds the has_two_way function to set up an two-way attribute.
Moo::BrightChild::Role - a child that knows who it's parents is/are.
I'm clueless on implementation details. Thought I'd throw the idea out there (and also hear if it exists). I would not know what names to search for.
CI Get details about the current CI environment
This module provides details about the current CI environment. This is a perl port of https://github.com/watson/ci-info.
- Do you think the name "CI" is appropriate?
- Do you think this module is useful?
- Any feedback is welcome.
Data::Ref Show access path items in deeply nested data structures
Data::Ref is used to show the complete path to all elements in a complex data structure consisting of Hash and/or Arrays.
Recently I have spent a fair bit of time manipulating some deeply nested JSON structures that have been read in via some JSON package. At times it has been difficult to determine the exact data path to any particular piece of data..
In addition to being deeply nested, the data is sometimes large, and there may be many elements in each object. The net result is this; it is quite difficult at times to determine the path to any particular element, as it is usually necessary to scroll through several screens of data.
I developed Data::Ref so that I can easily see how to reference any element appearing in the data.
The included demo scripts simply do one of the following: - read in a perl script that contains only data from an object, process with eval and then walk and display the paths to each element - much the same as previous, but read data from a JSON file
See test-files/tc03.pl for the test data.
Note: the standard Markdown code blocks are not behaving in the manner I would normally expect. I will add a short demo when I learn how to do it properly.
In the meantime, please see Data::Ref README.md which contains demos.