cicirello / count-action-users

Generates Shields endpoint with number of users of a GitHub Action

Vincent A Cicirello

	Sites where you can find me or my work
Web and social media
Software development
Publications

If you want to generate the equivalent to the above for your own GitHub profile, check out the cicirello/user-statistician GitHub Action.

count-action-users's Issues

Green as default color inconsistent with convention of blue for informational badges

Summary
The badges produced by count-action-users are informational, and not really status. The default color of green implies that some status check is passing, but that is not really what this is about. Shields typically uses blue for informational badges, and even has a custom color with that name.

Potential to be affected by secondary rate limits

Describe the bug
There is potential for the rate limit on the code search API to interact with some other GitHub secondary rate limits. This issue probably won't turn up under most normal use-cases of the action. It came up under development, when multiple push events triggered test cases multiple times within relatively short timespan.

To Reproduce
Steps to reproduce the behavior:

1. Configure a workflow that monitors multiple actions.
2. Run the workflow multiple times in succession.
3. Observe the secondary rate limit error message.

Expected behavior
Decrease likelihood of hitting rate limit (perhaps by adding a delay between queries).

Fix broken links in GitHub Marketplace listing

Summary

Relative links work in repo README files, but recently stopped working in the GitHub Marketplace. As a workaround, replace any relative links with absolute links.

BUG: Rare transient case 0 results from query when there should be results

Describe the bug
In months of use a single run gave count of 0 for one of the actions monitored that should have users. Rerunning action corrected it. The count should never be 0 for any action. The workflow running the count-action-users action to count an action's users should itself contribute to the count since it reference's the action in a workflow file.

To Reproduce
Has happened only once in hundreds of runs. Corrected itself on next run.

Expected behavior
Since 0 should be an impossible result, if query returns 0, simply don't update badge json file. And also log query result to workflow run output to provide debugging data if this rare case happens again.

Replace usage of GitHub Action's deprecated set-output command

Describe the bug
GitHub Actions has deprecated the set-output workflow command, which we are currently using for workflow outputs of the action. See https://github.blog/changelog/2022-10-11-github-actions-deprecating-save-state-and-set-output-commands/. That same link indicates the replacement.

To Reproduce
Steps to reproduce the behavior:

1. Run the action.
2. Inspect the workflow run.
3. Notice the deprecation warning.

Expected behavior
No deprecation warning.

Update documentation to specify more precisely what this counts

Summary
Specify in docs that this counts number of workflows that use an action.

Bump Python to 3.12 in CI/CD workflows when running unit tests

Summary

Bump Python to 3.12 in CI/CD workflows when running unit tests, in preparation for upgrading Python within Docker container for the action to 3.12.

Run only unit tests on pushes, and run all tests on PRs

Summary
This relates to #1. All tests are currently run during both PRs and Pushes. Under normal conditions this is desirable. However, the integration test runs the action itself, executing the API queries. If a PR is merged shortly after it is created, then the queries will be repeated in short succession during the associated push, possibly causing the queries to fail. Or if multiple pushes occur back to back in short succession, the same issue can occur.

How to Fix
A solution to #1 will help. But additionally, change workflow to run only the unit tests on pushes (the unit tests do not execute any queries). Keep all tests for PRs.

Provide example of how to link the badge to relevant search page

Summary
It is common practice to link status badges to relevant pages, etc (e.g., workflow runs, documentation, etc). For a user count badge, the most obvious is possibly a list of some sort of those using the action. This can be done by linking directly to a GitHub search results page with the equivalent query. Add an example to the documentation.