Summary
The badges currently generated are styled in a way that is based on Shields's "flat" style, although no actual dependency on Shields (generated entirely within the action). Some users of this GitHub action may use other shields badges in their repos using one of their other styles, and may prefer all of their repo badges to have a common style. Although one potential solution would be to replicate all of the shields styles within the action. that would seem overly redundant.
Proposed Solution
Keep the default behavior as the default (generate badges directly within the action including the way they are currently styled). Add an option via action inputs to generate JSON endpoints with the fields expected by shields, either instead of or in addition to generating the badges directly.
Users who like the default style can continue to use as is, keeping the performance benefit of serving the badge directly from the repo (e.g., already generated, and one http request directly to the badge). Users who want to match other shields styles can opt-in to generating a JSON endpoint instead, using shields to generate the badge (e.g., use shields's endpoint badge, passing url to JSON to Shields to generate the badge). That would also enable those users to pass Shields's query parameters to change style, etc.
Summary The badges currently generated are styled in a way that is based on Shields's "flat" style, although no actual dependency on Shields (generated entirely within the action). Some users of this GitHub action may use other shields badges in their repos using one of their other styles, and may prefer all of their repo badges to have a common style. Although one potential solution would be to replicate all of the shields styles within the action. that would seem overly redundant.
Proposed Solution Keep the default behavior as the default (generate badges directly within the action including the way they are currently styled). Add an option via action inputs to generate JSON endpoints with the fields expected by shields, either instead of or in addition to generating the badges directly.
Users who like the default style can continue to use as is, keeping the performance benefit of serving the badge directly from the repo (e.g., already generated, and one http request directly to the badge). Users who want to match other shields styles can opt-in to generating a JSON endpoint instead, using shields to generate the badge (e.g., use shields's endpoint badge, passing url to JSON to Shields to generate the badge). That would also enable those users to pass Shields's query parameters to change style, etc.