24 add badges to the readme file

[github-actions[bot]]

Code Coverage Summary

Filename                Stmts    Miss  Cover    Missing
--------------------  -------  ------  -------  ---------
R/grouped_barchart.R       12      12  0.00%    23-35
R/pyramid_chart.R          70      70  0.00%    43-117
R/utils.R                 284     284  0.00%    8-609
TOTAL                     366     366  0.00%

Diff against main

Filename      Stmts    Miss  Cover
----------  -------  ------  --------
TOTAL             0       0  +100.00%

Results for commit: 42b056e0ac46b9b90b46c144a2b2d0b9f8645fbf

Minimum allowed coverage is 80%

:recycle: This comment has been updated with latest results

[chen-chen-stat]

@Lovemore-Gakava I am struggling about whether we should specify run-names in the workflow files. Currently some workflow files have run-names and some do not. The result is that the display of workflow runs on the "Actions" tab are inconsistent. For workflow files that have run-names, the run-names are displayed for the workflow runs. For workflow files that do not have run-names, the commit messages are displayed for the workflow runs (in this case, you can still differentiate different workflow files, as the names of the workflow files are displayed in the sub-headers in smaller font). Originally I preferred specifying run-names so that we are clear about which workflow is doing what, but now I feel that having the commit messages for the workflow runs might be more informative because it helps us differentiate which workflow runs are for which commits when looking at the history of workflow runs. What is your opinion about this?

[Lovemore-Gakava]

@chen-chen-stat thanks for the comment: I understand the dilemma regarding the use of run-names in workflow files. Both approaches have their advantages and drawbacks.

Using run-names in workflow files can provide a more organized and clear display of workflow runs on the "Actions" tab. This approach allows us to explicitly name each workflow run, making it easier to identify which workflow is doing what at a glance. It can be particularly helpful when we have multiple workflow files running concurrently or when the workflow names themselves are not descriptive enough.

On the other hand, not using run-names and relying on commit messages to differentiate workflow runs can be more informative, as you pointed out. It provides valuable context about which commit triggered a particular workflow run, making it easier to correlate workflow runs with specific code changes or commits. This approach can be especially beneficial when we need to troubleshoot issues or track down the root cause of a failed workflow run.

In the future we can consider using a combination approach: we could explore a hybrid approach where we use run-names for some workflows and commit messages for others, based on their importance or use case.

For this repo I've updated all workflows to use run-names due to us having multiple workflow files running concurrently. If the use of run-names becomes cumbersome or lacks the desired level of information in the future, we can always reconsider the approach and explore alternatives.

[chen-chen-stat]

@chen-chen-stat thanks for the comment: I understand the dilemma regarding the use of run-names in workflow files. Both approaches have their advantages and drawbacks.

Using run-names in workflow files can provide a more organized and clear display of workflow runs on the "Actions" tab. This approach allows us to explicitly name each workflow run, making it easier to identify which workflow is doing what at a glance. It can be particularly helpful when we have multiple workflow files running concurrently or when the workflow names themselves are not descriptive enough.

On the other hand, not using run-names and relying on commit messages to differentiate workflow runs can be more informative, as you pointed out. It provides valuable context about which commit triggered a particular workflow run, making it easier to correlate workflow runs with specific code changes or commits. This approach can be especially beneficial when we need to troubleshoot issues or track down the root cause of a failed workflow run.

In the future we can consider using a combination approach: we could explore a hybrid approach where we use run-names for some workflows and commit messages for others, based on their importance or use case.

For this repo I've updated all workflows to use run-names due to us having multiple workflow files running concurrently. If the use of run-names becomes cumbersome or lacks the desired level of information in the future, we can always reconsider the approach and explore alternatives.

Thank you for summarizing the pros and cons of each approach nicely! I am fine with your proposal.

[github-actions[bot]]

Github pages

Review the pkgdown webpage for the PR here