• add Error method that coalesces the Results error messages into one error with the messages joined, comma-separated
• update Values only return non-error result values, Errors to only include errors from Results with errors
• add Example tests, update existing to reflect new logic

This PR suggests creating the maps package extracting these functions from utils/ — it is named maps to avoid conflict with Go's native map keyword.

On top of that:

• Adds docs top all public functions
• Adds examples top the docs of all public functions
• Adds tests for all public functions (only MapConcurrent was tested)
• Adds benchmark for all public functions

Breaking changes

No function passed as an argument expects the index as the last argument

| Function | Before | After | |---|---|---| | MapError | func(In, int) (Out, error) | func(In) (Out, error) | | MapContextError | func(context.Context, In, int) (Out, error) | func(context.Context, In) (Out, error) | | MapConcurrent | func(ctx context.Context, T1, int) (T2, error) | func(ctx context.Context, In) (Out, error) |

The reason is that this way functions don't need to internalize the business logic of the functional map (i.e. functions shouldn't care about the index). It looks like we're not using this indexes in the codebase, and we can wrap the error to provide the index in error messages (that is implemented in this PR).

• Add composite action to setup go and download deps
• Runs tests and benchmarks
• Runs example app and ensures build
• Add matrix support for different golang versions (I'm using 1.18.0 and 1.18.1 because they are the only ones supporting generics rn, but the idea is to be able to test again all major versions 1.18.x, 1.19.x and so on....)

• Should be accessible as hoff.Filter etc in consumer packages
• add common.go and define contextKey there so it doesn't get redeclared
• update some of the docs for flatmap, make errors lowercased in tests
• use make to create string slices in for_each_test
• gofmt auto-formatting

Original issue reported on Dec 3, 2021, no fix available yet: https://github.com/romeovs/lcov-reporter-action/issues/33

Fixed in this fork PR: https://github.com/osmind-development-org/lcov-reporter-action/pull/1

And released: https://github.com/osmind-development-org/lcov-reporter-action/releases/tag/v0.3.2

This PR adds a Unit test for the ForEach generic function.

To tophat:

• Run go test -v utils/forEach.go utils/forEach_test.go to test only the ForEach.
• Run go test -v to run the whole test suite.

What to look for:

• Hoping for suggestions on how I can refactor the test suite to reduce code duplication. I think there is potential to use generics inside the tests as well.

Hello 👋

We are deprecating probot usage, so all Shopify repos should be migrated to use new GitHub CLA Action.

You can see how this works in vscode-shopify-ruby repo.

If you have any questions, please reach us on Slack.

After you merge this PR, make sure to update branch protection settings (if you have any):

1. Go to Settings > Branches > Edit main (or any default) branch
2. Remove the CLA check from probot (click x):
3. Add CLA check from GitHub action:

Adds Go's standard docs badge linking to the official docs:

Since we don't have more badges yet, I suggested to leave it in the title line — we can move to a deidcated line once we add more badges ; )

• Copy over the utils from the observability monitoring api project along with existing tests
• These could be moved to the top-level if we don't want the utils package namespace?

I noticed there was a couple of pure text examples in Chunk's docs:

They are not well-formatted, making it difficult to follow. So I moved them to runnable examples, which looks better and are ran and tested automagically when we run go test:

• previously if the filter matched nothing, []T(nil) would be returned, rather than an actual empty slice []T{}
• this is because we weren't initializing the out return value, so if nothing matched the filter, it would just return the default value of nil
• add Example and "No Matches" tests

A readme is good, but a cool looking documentation page is like hitting the big leagues.

Develop a slick, cool looking homepage and publish on GH pages.

https://docs.github.com/en/pages/getting-started-with-github-pages/configuring-a-publishing-source-for-your-github-pages-site#choosing-a-publishing-source