diff --git a/.Rbuildignore b/.Rbuildignore index 6c6930af..2613eed2 100644 --- a/.Rbuildignore +++ b/.Rbuildignore @@ -18,3 +18,4 @@ TODO\.md ^\.gitlab-ci\.yml$ ^man-roxygen$ pkgdown +^pkgdown$ diff --git a/.github/ISSUE_TEMPLATE/cran-release.yaml b/.github/ISSUE_TEMPLATE/cran-release.yaml index 49a81e67..bab34fcf 100644 --- a/.github/ISSUE_TEMPLATE/cran-release.yaml +++ b/.github/ISSUE_TEMPLATE/cran-release.yaml @@ -29,12 +29,13 @@ body: validations: required: true - type: textarea - id: pre-requisites + id: pre-release attributes: - label: Pre-requisites + label: Pre-release description: Pre-requisites that must be fulfilled before initiating the release process. placeholder: Add your list of pre-requisites here. value: | + - [ ] Make sure you adhere to CRAN submission policy: https://cran.r-project.org/web/packages/submission_checklist.html; https://cran.r-project.org/web/packages/policies.html. - [ ] Make sure that high priority bugs (label "priority" + "bug") have been resolved before going into the release. - [ ] Review old/hanging PRs before going into the release (Optional). - [ ] Revisit R-package's lifecycle badges (Optional). @@ -42,54 +43,76 @@ body: - [ ] Make sure integration tests are green 2-3 days before the release. Look carefully through logs (check for warnings and notes). - [ ] Decide what gets merged in before starting release activities. - type: textarea - id: release-checklist + id: release attributes: - label: Release Checklist + label: Release description: The steps to be taken in order to create a release. placeholder: Steps to create a release. value: | + ### Prepare the release + + - [ ] Create a new release candidate branch + `git checkout -b release-candidate-vX.Y.Z` - [ ] Update NEWS.md file: make sure it reflects a holistic summary of what has changed in the package. - - [ ] Remove the additional fields (`Remotes` and `Config/Needs/*`) from the DESCRIPTION file where applicable. - - [ ] Increase versioned dependency on {package name} to >=X.X.X (Optional). + - [ ] Remove the additional fields (`Remotes`) from the DESCRIPTION file where applicable. - [ ] Make sure that the minimum dependency versions are updated in the DESCRIPTION file for the package and its reverse dependencies (Optional). - - [ ] Create a pull request to make necessary bug fixes/changes (add "[skip vbump]" in the pr title), and after merging the PR, tag the update(s) as a release candidate v < intended release version > -rc < release candidate iteration > on the main branch. + - [ ] Increase versioned dependency on {package name} to >=X.Y.Z (Optional). + - [ ] Commit your changes and create the PR on GitHub (add "[skip vbump]" in the PR title). Add all updates, commit, and push changes: + `# Make the necessary modifications to your files + # Stage the changes + git add + # Commit the changes + git commit -m "[skip vbump] " + git push origin release-candidate-vX.Y.Z` + + ### Test the release + + - [ ] Execute the manual tests on Shiny apps that are deployed on various hosting providers (Posit connect and shinyapps.io) - track the results in GitHub issue (Applicable only for frameworks that use Shiny). + - [ ] Monitor integration tests, if integration fails, create priority issues on the board. + - [ ] Execute UAT tests (Optional). + + ### CRAN submission + + - [ ] Tag the update(s) as a release candidate vX.Y.Z-rc (e.g. v0.5.3-rc1) on the release candidate branch (release-candidate-vX.Y.Z). + `# Create rc tag for submission for internal validation + git tag vX.Y.Z-rc + git push origin vX.Y.Z-rc` - [ ] Build the package locally using the command:`R CMD build .` which will generate a .tar.gz file necessary for the CRAN submission. - - [ ] Submit the package that was build in the previous step via this form: https://cran.r-project.org/submit.html. - - [ ] Address CRAN feedback, tag the package vX.X.X-rc(n+1) and repeat the submission to CRAN whenever necessary. + - [ ] Submit the package to https://win-builder.r-project.org/upload.aspx for testing, for more details please see "Building and checking R source packages for Windows": https://win-builder.r-project.org/. + - [ ] Once tested, send the package that was built in the previous steps to CRAN via this form: https://cran.r-project.org/submit.html. + - [ ] Address CRAN feedback, tag the package vX.Y.Z-rc(n+1) and repeat the submission to CRAN whenever necessary. - [ ] Get the package accepted and published on CRAN. - - [ ] If the additional fields were removed, add them back in a separate PR, and then merge the PR back to main. Note: Take precautionary measures to ensure that the version bump does not take place on a merge. - - [ ] Create a git tag with the final version set to X.X.X on the main branch. - - type: textarea - id: testing - attributes: - label: Testing - description: Summary of testing activities - integration tests, UAT, other - placeholder: Tests results - value: | - - [ ] Integration tests results - accepted. - - [ ] UAT results - accepted. - - [ ] All testing activities are finalized. - - type: textarea - id: feedback - attributes: - label: Release Feedback - description: Feedback received from CRAN/testers. - placeholder: Feedback to be implemented after CRAN submission/testing. - value: | - - [ ] Fix 1 - - [ ] Enhancement 1 - - [ ] Defect 1 + + ### Tag the release + + - [ ] If the additional fields were removed, add them back in a separate PR, and then merge the PR back to main (add "[skip vbump]" in the PR title). If nothing was removed just merge the PR you created in the "Prepare the release" section to 'main'. Note the commit hash of the merged commit. **Note:** additional commits might be added to the `main` branch by a bot or an automation - we do **NOT** want to tag this commit. + + ### Make sure of the following before continuing + + - [ ] CI checks are passing in GH before releasing the package. + - [ ] Shiny apps are deployable and there are no errors/warnings (Applicable only for frameworks that use Shiny). + + - [ ] Create a git tag with the final version set to vX.Y.Z on the main branch. In order to do this: + 1. Checkout the commit hash. + `git checkout ` + 2. Tag the hash with the release version (vX.Y.Z). + `git tag vX.Y.Z` + 3. Push the tag to make the final release. + `git push origin vX.Y.Z` + - [ ] Update downstream package dependencies to (>=X.Y.Z) in {package name}. + Note: Once the release tag is created, the package is automatically published to internal repositories. - type: textarea id: post-release attributes: - label: Post-release Checklist + label: Post-release description: The list of activities to be completed after the release. placeholder: The steps that must be taken after the release. value: | + - [ ] Ensure that CRAN checks are passing for the package. - [ ] Make sure that the package is published to internal repositories. + - [ ] Make sure internal documentation is up to date. - [ ] Review and update installation instructions for the package wherever needed (Optional). - [ ] Update all integration tests to reference the new release. - - [ ] Ensure a new dev version (.9XXX) is added to the NEWS.md file and DESCRIPTION file as a placeholder for release notes. - [ ] Announce the release on ________. - type: textarea id: decision-tree diff --git a/.github/ISSUE_TEMPLATE/release.yaml b/.github/ISSUE_TEMPLATE/release.yaml index 1d97dff5..73bb11dc 100644 --- a/.github/ISSUE_TEMPLATE/release.yaml +++ b/.github/ISSUE_TEMPLATE/release.yaml @@ -28,72 +28,87 @@ body: validations: required: true - type: textarea - id: pre-requisites + id: pre-release attributes: - label: Pre-requisites + label: Pre-release description: Pre-requisites that must be fulfilled before initiating the release process. placeholder: Add your list of pre-requisites here. value: | - [ ] Make sure that high priority bugs (label "priority" + "bug") have been resolved before going into the release. - [ ] Review old/hanging PRs before going into the release. - [ ] Revisit R-package's lifecycle badges (Optional). - - [ ] Discuss package dependencies before going into release activities. - - [ ] Create a plan to sequentially close release activities and submit groups of packages for internal validation (Applicable only for regulatory release). + - [ ] Release Manager: Discuss package dependencies, create a plan to sequentially close release activities and submit groups of packages for internal validation (Applicable only for regulatory release). + - [ ] Check Validation Pipeline dry-run results for the package. - [ ] Make sure all relevant integration tests are green 2-3 days before the release. Look carefully through logs (check for warnings and notes). - - [ ] Check if a package is installable on our supported internal systems (Optional). - [ ] Inform about the soft code freeze, decide what gets merged in before starting release activities. - type: textarea - id: release-checklist + id: release attributes: - label: Release Checklist + label: Release description: The steps to be taken in order to create a release. placeholder: Steps to create a release. value: | - - [ ] Recurring tasks: Execute the manual tests on Shiny apps that are deployed on various hosting providers (Posit connect and shinyapps.io) - track the results in GitHub issue (Applicable only for frameworks that use Shiny). - - [ ] Recurring tasks: Monitor integration tests, if integration fails, create priority issues on the board. - - [ ] Sanity checks for Shiny applications e.g. checking if Shiny apps are deployable and making sure there are no errors/warnings. + ### Prepare the release + + - [ ] Create a new release candidate branch + `git checkout -b release-candidate-vX.Y.Z` - [ ] Update NEWS.md file: make sure it reflects a holistic summary of what has changed in the package, check README. - - [ ] Remove the additional fields (`Remotes` and `Config/Needs/*`) from the DESCRIPTION file where applicable. + - [ ] Remove the additional fields (`Remotes`) from the DESCRIPTION file where applicable. - [ ] Make sure that the minimum dependency versions are updated in the DESCRIPTION file for the package. - - [ ] Increase versioned dependency on {package name} to >=X.X.X. - - [ ] Create a pull request to make necessary bug fixes/changes (add "[skip vbump]" in the PR title), and after merging the PR, tag the update(s) as a release candidate v < intended release version > -rc < release candidate iteration > on the main branch. Note that tags are created in GitHub and synchronized with GitLab automatically. - - [ ] The package is submitted for internal validation by Release Coordinator (Applicable only for regulatory release). - - [ ] Address any feedback (internal validation/user testing), retag the package as a release candidate vX.X.X-rc(n+1). Repeat the submission for internal validation if necessary. - - [ ] Get the package validated (Applicable only for regulatory release). - - [ ] If the additional fields were removed, add them back in a separate PR, and then merge the PR back to main (add "[skip vbump]" in the PR title). - - [ ] Create a git tag with the final version set to X.X.X on the main branch. - - [ ] Update downstream package dependencies to (>=X.X.X) in {package name}. - - type: textarea - id: testing - attributes: - label: Testing - description: Summary of testing activities - integration tests, UAT, other. - placeholder: Tests results - value: | - - [ ] Integration tests results - accepted. - - [ ] UAT results - accepted. - - [ ] Shiny apps test results - accepted (Applicable only for Shiny apps). - - [ ] Necessary testing on target environment - performed (up to ETL). - - type: textarea - id: feedback - attributes: - label: Release Feedback - description: Feedback received from internal validation/UAT testers. - placeholder: Feedback to be implemented after submission for internal validation/testing. - value: | - - [ ] Fix 1 - - [ ] Enhancement 1 - - [ ] Defect 1 + - [ ] Increase versioned dependency on {package name} to >=X.Y.Z. + - [ ] Commit your changes and create the PR on GitHub (add "[skip vbump]" in the PR title). Add all updates, commit, and push changes: + `# Make the necessary modifications to your files + # Stage the changes + git add + # Commit the changes + git commit -m "[skip vbump] " + git push origin release-candidate-vX.Y.Z` + + ### Test the release + + - [ ] Execute the manual tests on Shiny apps that are deployed on various hosting providers (Posit connect and shinyapps.io) - track the results in GitHub issue (Applicable only for frameworks that use Shiny). + - [ ] Monitor integration tests, if integration fails, create priority issues on the board. + - [ ] Execute UAT tests (Optional). + + ### Validation loop + + Note: This section is applicable only for regulatory packages. + + - [ ] Tag the update(s) as a release candidate vX.Y.Z-rc (e.g. v0.5.3-rc1) on the release candidate branch (release-candidate-vX.Y.Z). + `# Create rc tag for submission for internal validation + git tag vX.Y.Z-rc + git push origin vX.Y.Z-rc` + - [ ] Submit the package for internal validation. + - [ ] Address any feedback (internal validation/user testing), retag the package as a release candidate vX.Y.Z-rc(n+1). Repeat the submission for internal validation if necessary. + - [ ] Get the package validated. + + ### Tag the release + + - [ ] If the additional fields were removed, add them back in a separate PR, and then merge the PR back to main (add "[skip vbump]" in the PR title). If nothing was removed just merge the PR you created in the "Prepare the release" section to `main`. Note the commit hash of the merged commit. **Note:** additional commits might be added to the `main` branch by a bot or an automation - we do **NOT** want to tag this commit. + + #### Make sure of the following before continuing with the release: + + - [ ] CI checks are passing in GH. + - [ ] Shiny apps are deployable and there are no errors/warnings (Applicable only for frameworks that use Shiny). + + - [ ] Create a git tag with the final version set to vX.Y.Z on the main branch. In order to do this: + 1. Checkout the commit hash. + `git checkout ` + 2. Tag the hash with the release version (vX.Y.Z). + `git tag vX.Y.Z` + 3. Push the tag to make the final release. + `git push origin vX.Y.Z` + - [ ] Update downstream package dependencies to (>=X.Y.Z) in {package name}. + Note: Once the release tag is created, the package is automatically published to internal repositories. - type: textarea id: post-release attributes: - label: Post-release Checklist + label: Post-release description: The list of activities to be completed after the release. placeholder: The steps that must be taken after the release. value: | - [ ] Make sure that the package is published to internal repositories (Validated and/or Non-Validated repository). - [ ] Review and update installation instructions for the package if needed. - - [ ] Verify if a new dev version (.9XXX) has been added to the NEWS.md file and DESCRIPTION file as a placeholder for release notes by automation. - [ ] Make sure internal documentation/documentation catalogs are up to date. - [ ] Notify the IDR team to start post-release/clean-up activities. - [ ] Announce the release on ________. diff --git a/.github/workflows/check.yaml b/.github/workflows/check.yaml index 71f0b7f0..c28e3239 100644 --- a/.github/workflows/check.yaml +++ b/.github/workflows/check.yaml @@ -34,6 +34,7 @@ jobs: checking S3 generic/method consistency .* NOTE checking Rd .usage sections .* NOTE checking for unstated dependencies in vignettes .* NOTE + checking top-level files .* NOTE unit-test-report-brand: >- https://raw.githubusercontent.com/insightsengineering/hex-stickers/main/thumbs/rlistings.png coverage: diff --git a/.github/workflows/release.yaml b/.github/workflows/release.yaml index 7e0a0479..b8deae29 100644 --- a/.github/workflows/release.yaml +++ b/.github/workflows/release.yaml @@ -47,6 +47,7 @@ jobs: checking R code for possible problems .* NOTE checking examples .* NOTE checking Rd line widths .* NOTE + checking top-level files .* NOTE unit-test-report-brand: >- https://raw.githubusercontent.com/insightsengineering/hex-stickers/main/thumbs/rlistings.png coverage: diff --git a/.pre-commit-config.yaml b/.pre-commit-config.yaml index 58fbea31..eb87da44 100644 --- a/.pre-commit-config.yaml +++ b/.pre-commit-config.yaml @@ -3,9 +3,9 @@ repos: - repo: https://github.com/lorenzwalthert/precommit rev: v0.3.2.9027 - hooks: + hooks: # - id: style-files - # args: [--style_pkg=styler, --style_fun=tidyverse_style] + # args: [--style_pkg=styler, --style_fun=tidyverse_style] - id: roxygenize name: Regenerate package documentation additional_dependencies: @@ -29,14 +29,14 @@ repos: .*\.Rproj| .*\.sh| (.*/|)\.gitignore| - (.*/|)\.gitlab-ci\.yml| + (.*/|)\.gitlab-ci\.y[a]?ml| (.*/|)\.lintr| (.*/|)\.pre-commit-.*| (.*/|)\.Rbuildignore| (.*/|)\.Renviron| (.*/|)\.Rprofile| - (.*/|)\.travis\.yml| - (.*/|)appveyor\.yml| + (.*/|)\.travis\.y[a]?ml| + (.*/|)appveyor\.y[a]?ml| (.*/|)NAMESPACE| (.*/|)renv/settings\.dcf| (.*/|)renv\.lock| @@ -52,7 +52,7 @@ repos: - id: deps-in-desc - repo: https://github.com/pre-commit/pre-commit-hooks rev: v4.5.0 - hooks: + hooks: - id: check-added-large-files args: ['--maxkb=200'] - id: file-contents-sorter