Merge pull request #18 from phuse-org/docs/code-coverage-updates

Removes references to badges and other IE-specific workflow features

README.md

@@ -1,4 +1,4 @@
-<img align="right" width="250" height="250" src="https://github.com/phuse-org/devops/blob/main/assets/PharmaDevOps.png?raw=true"> 
+<img align="right" width="250" height="250" src="https://github.com/phuse-org/devops/blob/main/assets/PharmaDevOps.png?raw=true">
 
 # PharmaDevOps
 

content/cicdworkflows-enhanced/_metadata.yaml

@@ -1,4 +1,4 @@
 comments:
-  giscus: 
+  giscus:
     repo: phuse-og/devops
     category: General

content/cicdworkflows-enhanced/posts/validate/validate.qmd

@@ -1,7 +1,7 @@
 ---
 title: "theValidator"
 description: |
-  This workflow will take your documentation, and link it to unit testing, creating a report that links requirements (documentation) to tests of those requirements. 
+  This workflow will take your documentation, and link it to unit testing, creating a report that links requirements (documentation) to tests of those requirements.
 categories:
   - Testing
   - Documentation
@@ -21,23 +21,23 @@ toc: true
 
 ## Why should I use this?
 
-Validation is not a fixed term, and it is strongly recommended to make yourself aware of the work of the R Validation Hub (https://www.pharmar.org/), including the 
+Validation is not a fixed term, and it is strongly recommended to make yourself aware of the work of the R Validation Hub (https://www.pharmar.org/), including the
 regulatory repo project.
 
-When using an R package, it is important to know that what the documentation claims the package does is tested, and these tests pass on the 
-environment you will be using. This gh-action generates a generic report, that takes the documentation and links it to the 
-unit tests, and records how the the tests performed against a specific R environment. 
+When using an R package, it is important to know that what the documentation claims the package does is tested, and these tests pass on the
+environment you will be using. This gh-action generates a generic report, that takes the documentation and links it to the
+unit tests, and records how the the tests performed against a specific R environment.
 
-The aim here is to who in a pan-company way to document the relationship between documentation and tests. Before 
-using internally, you would need to 1) confirm the documentation is well written, 2) the unit tests are sufficient to 
+The aim here is to who in a pan-company way to document the relationship between documentation and tests. Before
+using internally, you would need to 1) confirm the documentation is well written, 2) the unit tests are sufficient to
 test that documentation and 3) you are assessing against the actual environments you use internally.
 
 ## How do I set it up?
 
 Below is an example of using this `gh-action` when a release is made.
 
 
-```bash
+```yaml
 ---
 name: R Package Validation report
 

content/cicdworkflows-minimum/_metadata.yaml

@@ -1,4 +1,4 @@
 comments:
-  giscus: 
+  giscus:
     repo: phuse-og/devops
     category: General

content/cicdworkflows-minimum/posts/code-coverage.qmd

@@ -1,10 +1,11 @@
 ---
-title: "Code coverage"
+title: "Check code coverage"
 description: |
-  This workflow checks whether URLs embedded in code and documentation are valid. Invalid URLs result in workflow failures. 
+  This workflow measures code coverage for unit tests and reports the code coverage as a percentage of the total number of lines covered by unit tests vs. the total number of lines in the codebase.
 categories:
-  - Documentation
-  - Links
+  - Testing
+  - R
+author: Pharmaverse
 date: 2023-08-01
 image: https://covr.r-lib.org/reference/figures/logo.png
 toc: true
@@ -14,9 +15,6 @@ toc: true
 ## About the gh-action
 
 **Example of use:** [falcon R package](https://github.com/pharmaverse/falcon/blob/use-phuse-cicd/.github/workflows/phuse-basics.yml)
-
-**Expected output:** Badge (![Code
-Coverage](https://github.com/pharmaverse/admiralci/actions/workflows/code-coverage.yml/badge.svg)) or change pipeline depending on reported code coverage.
 :::
 
 ## Why should I use this?
@@ -25,21 +23,18 @@ This workflow measures code coverage for unit tests and reports the code
 coverage as a percentage of the *total number of lines covered by unit
 tests* vs. the *total number of lines in the codebase* in an R package.
 
-Using this github action gives you a badge that helps to show that the code is coverage. Calculating this 
-via CICD is useful as the amount of untested code can vary, e.g. a new feature is added but it is not tested. People often use this metric as an indicator of code quality and maturity.
-
-It's important to note that code coverage is only telling you if a test exists, not that the test is 
-testing all that should be tested against that line of code. 
+It's important to note that code coverage is only telling you if a test exists, not that the test is
+testing all that should be tested against that line of code.
 
-For information on how to add testing to R packages, [R-pkgs.org](https://r-pkgs.org/testing-basics.html) covers 
-setting up tests with test that. 
+For information on how to add testing to R packages, [R-pkgs.org](https://r-pkgs.org/testing-basics.html) covers
+setting up tests with test that.
 
 ## How do I set it up?
 
-You can call this action via adding a call to this job in a github action. A minimal example 
+You can call this action via adding a call to this job in a GitHub Actions workflow. A minimal example
 that runs this on commits to master is:
 
-```bash
+```yaml
 name: Code coverage
 # sourced from phuse-org/devops-toolkit
 
@@ -65,93 +60,4 @@ jobs:
 
 ## The deets
 
-The [`covr`](https://covr.r-lib.org/) R package is used to calculate the
-coverage.
-
-Report summaries and badges for coverage are generated using a series of
-other GitHub Actions.
-
-For this workflow to execute successfully, you will need to create an
-orphan branch called `badges` in your GitHub repository. You can do that
-using the following steps:
-
-```bash
-# Create orphan branch
-git checkout --orphan badges
-# Back up files
-mv .git /tmp/.git-backup
-# Remove everything else
-rm -rf * .*
-# Restore git files
-mv /tmp/.git-backup .git
-# Create a README file
-echo "# Badges" > README.md
-# Add, commit and push your new branch
-git add . && git commit -m "Init badges" && git push origin badges
-```
-
----
-title: "Check code coverage"
-description: |
-  This workflow measures code coverage for unit tests and reports the code coverage as a percentage of the total number of lines covered by unit tests vs. the total number of lines in the codebase. 
-categories:
-  - Testing
-  - R
-author: Pharmaverse
-date: 2023-08-01
-image: https://covr.r-lib.org/reference/figures/logo.png
-toc: true
----
-
-:::{.callout-note style="margin-top: 0rem;" collapse="false"}
-## About the gh-action
-
-**Lifecycle stage:** Not reported 
-
-**Example of use:** [admiral R package](https://github.com/pharmaverse/admiralci#links)
-
-**Source:** Pharmaverse gh-action maintained by Roche/Genentech
-
-**Expected output:** Stop or warn in pipeline if links are broken.
-:::
-
-## Why should I use this?
-
-As your documentation grows, it's likely the number of links present do as well. This
-gh-action helps to make sure that if you link to an external website, you can be informed 
-if that link stops working.
-
-## How do I set it up?
-
-You can call this action via adding a call to this job in a github action. A minimal example that runs this on PRs to `main` is:
-
-```bash
----
-# Source: https://github.com/pharmaverse/admiralci
-# Common workflows designed for Admiral
-# but can be easily used by any other R package
-name: admiral CI/CD Workflows
-
-on:
-  push:
-    branches:
-      - main
-  # 'pull_request' events are triggered when PRs are
-  # created against one of these target branches.
-  pull_request:
-    branches:
-      - main
-
-jobs:
-  links:
-    name: Links
-    uses: pharmaverse/admiralci/.github/workflows/links.yml@main
-    if: github.event_name == 'pull_request'
-```
-
-## The deets
-
-This gh-action uses lychee. If there are false positives, you can 
-create a `.lycheeignore` file. There is an example [here of how this is 
-done in `admiral`](https://github.com/pharmaverse/admiral/blob/devel/.lycheeignore).
-
+The [`covr`](https://covr.r-lib.org/) R package is used to calculate the coverage.

content/cicdworkflows-minimum/posts/pkgdown.qmd

@@ -20,22 +20,22 @@ toc: true
 
 ## Why should I use this?
 
-`pkgdown` is the most common framework for rendering R package documentation into a an HTML website. This `gh-action` will 
-generate the documentation, and deploy it to a gh-pages branch. It will also upload a copy of the documentation to the release. 
+`pkgdown` is the most common framework for rendering R package documentation into a an HTML website. This `gh-action` will
+generate the documentation, and deploy it to a gh-pages branch. It will also upload a copy of the documentation to the release.
 
 This is important for multiple reasons:
 
 1. Because the documentation is generated automatically, you can make sure the documentation matches the code. Without CICD you are relying on users remembering to rebuild the documentation when they make changes.
 1. If you manually generate the documentation, you will need to store the built artefacts in your git repo. This will bloat your repo, and make it harder to work with.
-1. Because the documentation is versioned, you can always find the documentation that matches the version of the code you are using. This is important for reproducibility. 
+1. Because the documentation is versioned, you can always find the documentation that matches the version of the code you are using. This is important for reproducibility.
 
 
 ## How do I set it up?
 
-You can call this action via adding a call to this job in a github action. A minimal example 
+You can call this action via adding a call to this job in a GitHub Actions workflow. A minimal example
 that runs this on commits to main is:
 
-```bash
+```yaml
 ---
 name: Docs 📚
 
@@ -52,7 +52,7 @@ jobs:
 
 ## The deets
 
-If you have built docs locally in the past, you are probably aware that your git repo will balloon in size, as it stores a copy 
-of each piece version of every plot and image you have used in your documentation. This `gh-action` will help you avoid that, by 
+If you have built docs locally in the past, you are probably aware that your git repo will balloon in size, as it stores a copy
+of each piece version of every plot and image you have used in your documentation. This `gh-action` will help you avoid that, by
 placing the versioned documentation into an orphan branch. Helping to keep your docs (a built artefact) seperate from your source code.
 

content/cicdworkflows-minimum/posts/r-cmd-check/r-cmd-check.qmd

@@ -1,7 +1,7 @@
 ---
 title: "R CMD Check"
 description: |
-  Ensure that when you release your package, all the unit tests are passing and it works in a clean environment. 
+  Ensure that when you release your package, all the unit tests are passing and it works in a clean environment.
 categories:
   - Testing
 date: 2023-08-23
@@ -19,9 +19,9 @@ toc: true
 
 ## Why should I use this?
 
-`R CMD Check` has [around 50 checks](https://r-pkgs.org/R-CMD-check.html), but the general jist is it will check your package is fit to install, and as part of that process run the unit tests. In many companies, you will 
-be running potentially multiple versions of R in parrallel. To reflect 
-that, this gh-action is updated to run across the last 3 R major versions, 
+`R CMD Check` has [around 50 checks](https://r-pkgs.org/R-CMD-check.html), but the general jist is it will check your package is fit to install, and as part of that process run the unit tests. In many companies, you will
+be running potentially multiple versions of R in parrallel. To reflect
+that, this gh-action is updated to run across the last 3 R major versions,
 using a snapshot from the Posit Public Package Manager that reflects a relevant time frame for when that R version was latest.
 
 If you have dependencies on other pharmaverse packages, it's likely you will also want to run `R CMD Check` using CRAN today + the bleading edge of the pharmaverse (which may be pre-CRAN) via pointing at their r-universe. If this is the case, please see the advanced usage below.
@@ -31,7 +31,7 @@ If you have dependencies on other pharmaverse packages, it's likely you will als
 Below is an example of using this `gh-action` whenever someone tries to make PR into your `main` or `devel` branch or updates the branch. We recomend you use this on both `main` and `devel` branches, as it will help you catch issues before they get into your main branch.
 
 
-```bash
+```yaml
 name: Run R-CMD-check
 # sourced from phuse-org/devops-toolkit
 

content/cicdworkflows-recommend/_metadata.yaml

@@ -1,4 +1,4 @@
 comments:
-  giscus: 
+  giscus:
     repo: phuse-og/devops
     category: General

content/cicdworkflows-recommend/posts/check-links/check-links.qmd

@@ -1,7 +1,7 @@
 ---
 title: "Check links"
 description: |
-  This workflow checks whether URLs embedded in code and documentation are valid. Invalid URLs result in workflow failures. 
+  This workflow checks whether URLs embedded in code and documentation are valid. Invalid URLs result in workflow failures.
 categories:
   - Documentation
   - Links
@@ -20,7 +20,7 @@ toc: true
 
 ## Why should I use this?
 
-As a codebase grows, it becomes more likely you will end up with a number of links in your documentation. 
+As a codebase grows, it becomes more likely you will end up with a number of links in your documentation.
 These links can stop working over time - and often you won't know till a user flags your links are broken.
 
 This `gh-action` lets you stay on top of broken links, by actively scanning for them.
@@ -30,7 +30,7 @@ This `gh-action` lets you stay on top of broken links, by actively scanning for
 Below is an example of using this `gh-action` whenever someone tries to make PR into your `main` or `devel` branch.
 
 
-```bash
+```yaml
 name: Check URLs in docs 📚
 # sourced from phuse-org/devops-toolkit