diff --git a/dev/articles/git_usage.html b/dev/articles/git_usage.html index 0da8a23a..cc733913 100644 --- a/dev/articles/git_usage.html +++ b/dev/articles/git_usage.html @@ -118,26 +118,20 @@

IntroductionBranches

@@ -154,46 +148,34 @@

Implementing an IssueNaming Branches

The name of the branch must be prefixed with the issue number, -followed by a short but meaningful description and the -@<target_branch> suffix. The latter would be -@devel in most cases. As an example, given an issue #94 -“Program function to derive LSTALVDT”, the branch name -would be 94_derive_var_lstalvdt@devel.

-

The @<target_branch> suffix is used in our CI/CD -pipelines, e.g. when running R CMD check. It ensures that -admiral’s dependencies such as -pharmaversesdtm and admiraldev are -installed from the specified target branch. So when the target branch is -set to @devel the dependencies will be installed from those -package’s respective devel branches rather than installing -the latest released version. This ensures that we test the development -version of admiral against the development versions of -its dependencies. That way all packages are kept in sync.

+followed by a short but meaningful description. As an example, given an +issue #94 “Program function to derive LSTALVDT”, the branch +name would be 94_derive_var_lstalvdt.

-

Create a New Feature Branch from the Terminal (from -devel) +

Create a New Feature Branch from the Terminal (from +main)

-

Create a New Feature Branch from GitHub (from -devel) +

Create a New Feature Branch from GitHub (from +main)

You can also create a feature branch in GitHub.

@@ -280,10 +262,11 @@

Pull request

The issue must be linked to the pull request in the “Development” field of the Pull Request. In most cases, this will linkage will automatically close the issue and move to the Done column on our project @@ -296,7 +279,6 @@

Pull request

Reviewing/Closing an Issue

@@ -324,10 +306,10 @@

Solving Merge Confli part of a file. This typically happens when multiple people update the same part of code. Those conflicts always need to be handled manually (as some further code updates may be required):

-
git checkout devel
+
git checkout main
 git pull
 git checkout <feature_branch>  
-git merge devel

+git merge main

This provides a list of all files with conflicts In the file with conflicts the conflicting sections are marked with <<<<<<<, =======, and diff --git a/dev/articles/github_create_pr.png b/dev/articles/github_create_pr.png index de44a1d3..ac90c994 100644 Binary files a/dev/articles/github_create_pr.png and b/dev/articles/github_create_pr.png differ diff --git a/dev/articles/github_done.png b/dev/articles/github_done.png index 7c94e919..af04e38a 100644 Binary files a/dev/articles/github_done.png and b/dev/articles/github_done.png differ diff --git a/dev/articles/github_feature_branch.png b/dev/articles/github_feature_branch.png index 5d71d700..c61ff258 100644 Binary files a/dev/articles/github_feature_branch.png and b/dev/articles/github_feature_branch.png differ diff --git a/dev/articles/github_linked_issues_dark.png b/dev/articles/github_linked_issues_dark.png index e8ccd90d..d2e45329 100644 Binary files a/dev/articles/github_linked_issues_dark.png and b/dev/articles/github_linked_issues_dark.png differ diff --git a/dev/articles/package_extensions.html b/dev/articles/package_extensions.html index 9e04e157..4e35e2c4 100644 --- a/dev/articles/package_extensions.html +++ b/dev/articles/package_extensions.html @@ -184,7 +184,12 @@

Step-by-step Guidan {admiral} dummy issue for onboarding, as well as reading up on the admiraldev documentation, - especially the developer guides, which all need to -be followed for package extensions. Dummy issue for new developers

+be followed for package extensions.

+ +
+

Dummy issue for new developers

+
+

  1. Optionally it can be useful to host a kick-off meeting to decide how the team will work, for which we recommend agile/scrum practices.

    2. diff --git a/dev/articles/pr_review_checkbox.png b/dev/articles/pr_review_checkbox.png index 6a147232..8fecef83 100644 Binary files a/dev/articles/pr_review_checkbox.png and b/dev/articles/pr_review_checkbox.png differ diff --git a/dev/articles/pr_review_checklist.png b/dev/articles/pr_review_checklist.png index 64973f90..d8644fa3 100644 Binary files a/dev/articles/pr_review_checklist.png and b/dev/articles/pr_review_checklist.png differ diff --git a/dev/articles/pr_review_guidance.html b/dev/articles/pr_review_guidance.html index 74e95c2d..afbb6118 100644 --- a/dev/articles/pr_review_guidance.html +++ b/dev/articles/pr_review_guidance.html @@ -106,17 +106,17 @@

    Introductionadmiral package family. PR authors will benefit from shorter review times by closely following the guidance provided here.

    -

    A pull request into the devel branch signifies that an +

    A pull request into the main branch signifies that an issue has been “addressed”. This issue might be a bug, a feature request or a documentation update. Once a Pull Request is merged into -devel branch, then the issue(s) can be closed.

    +main branch, then the issue(s) can be closed.

    Closely following the below guidance will ensure that our all our -“addressed” issues auto-close once we merge devel.

    +“addressed” issues auto-close once we merge main.

Review Criteria

-

For a pull request to be merged into devel it needs to +

For a pull request to be merged into main it needs to pass the automated CI checks that will appear at the bottom of the Pull Request. In addition, the PR creator and reviewer should make sure that

@@ -217,7 +217,7 @@

Complete the Pull Request checklist done you due diligence in creating a compliant Pull Request. GitHub will refresh the Pull Request and trigger task-list-completed workflow that you have completed the task. The PR can not be merged into -devel until the contributor has checked off each of the +main until the contributor has checked off each of the check box items.

Please don’t hesitate to reach out to the admiral team @@ -227,8 +227,7 @@

Complete the Pull Request checklist clarity is needed on a check box item.

Note for Reviewers: We recommend the use of Squash and Merge when merging in a Pull Request. This will create a clean -commit history when doing a final merge of devel into -main.

+commit history.

@@ -243,133 +242,9 @@

GitHub Actions/CI Workflows

A synopsis of admiral’s workflows

-

Most workflows have a BEGIN boilerplate steps and -END boilerplate steps section within them which define some -standard steps required for installing system dependencies, R version -and R packages which serve as dependencies for the package.

-

The underlying mechanisms for installing R and Pandoc are defined in -r-lib/actions, while the installation of system -dependencies and R package dependencies is managed via the Staged -Dependencies GitHub Action]. The latter is used in conjunction with the -staged_dependencies.yaml file in order to install -dependencies that are in the same stage of development as the -current package.

-

Following the installation of system dependencies, R, and package -dependencies, each workflow checks the integrity of a specific component -of the admiral codebase.

-
-

-check-templates.yml -

-

This workflow checks for issues within template scripts. For example, -in the admiral package there are several template scripts with -admiral-based functions showing how to build certain ADaM datasets. As -we update the admiral functions, we want to make sure these template -scripts execute appropriately. Functions in the template scripts that -are deprecated or used inappropriately will cause this workflow to fail. -Click on the details button on a failing action provides information on -the where the template is failing.

-
-
-

-code-coverage.yml -

-

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.

-

The covr R package is used to calculate the -coverage.

-

Report summaries and badges for coverage are generated using a series -of other GitHub Actions.

-
-
- -

This workflow checks whether URLs embedded in code and documentation -are valid. Invalid URLs results in workflow failures. This workflow uses -lychee to detect broken links. Occasionally this check will -detect false positives of urls that look like urls. To remedy, please -add this false positive to the .lycheeignore file.

-
-
-

-lintr.yml -

-

Static code analysis is performed by this workflow, which in turn -uses the lintr R package. The .lintr -configurations in the repository will be by this workflow.

-
-
-

-man-pages.yml -

-

This workflow checks if the manual pages in the man/ -directory of the package are up-to-date with ROxygen comments in the -code.

-

Workflow failures indicate that the manual pages are not up-to-date -with ROxygen comments, and corrective actions are provided in the -workflow log.

-
-
-

-pkgdown.yml -

-

Documentation for the R package is generated via this workflow. This -workflow uses the pkgdown framework to generate -documentation in HTML, and the HTML pages are deployed to the -gh-pages branch.

-

Moreover, an additional Versions dropdown is generated -via the multi-version-docs GitHub Action, so that an end -user can view multiple versions of the documentation for the -package.

-
-
-

-r-cmd-check.yml -

-

This workflow performs R CMD check for the package. -Failed workflows are typically indicative of problems encountered during -the check, and therefore an indication that the package does not meet -quality standards.

-
-
-

-r-pkg-validation.yml -

-

When a new release of the package is made, this workflow executes to -create a validation report via validation action. The PDF -report is then attached to the release within GitHub.

-
-
-

-readme-render.yml -

-

If your codebase uses a README.Rmd file, then this -workflow will automatically render a README.md and commit -it to your branch.

-
-
-

-spellcheck.yml -

-

Spellchecks are performed by this workflow, and the -spelling R package is used to detect spelling mistakes. -Failed workflows typically indicate misspelled words. In the -inst/WORDLIST file, you can add words and or acronyms that -you want the spell check to ignore, for example occds is not an English -word but a common acronym used within Pharma. The workflow will flag -this until a user adds it to the inst/WORDLIST.

-
-
-

-style.yml -

-

Code style is enforced via the styler R package. Custom -style configurations, if any, will be honored by this workflow. Failed -workflows are indicative of unstyled code.

-
+

We recommend checking out the README +on the admiralci repository to gain an understanding of the +workflows/actions used in admiral.