diff --git a/.github/ISSUE_TEMPLATE/cran-release.yaml b/.github/ISSUE_TEMPLATE/cran-release.yaml deleted file mode 100644 index bab34fcf..00000000 --- a/.github/ISSUE_TEMPLATE/cran-release.yaml +++ /dev/null @@ -1,124 +0,0 @@ ---- -name: 🎉 CRAN Release -description: Template for release to CRAN -title: "[Release]: " -labels: ["release"] -assignees: - - KlaudiaBB - - cicdguy - - shajoezhu -body: - - type: markdown - attributes: - value: | - ⚠️ Please do not link or mention any internal references in this issue. This includes internal URLs, intellectual property and references. - - type: textarea - id: blocked-by - attributes: - label: Blocked by - description: Any PRs or issues that this release is blocked by. - placeholder: Add a list of blocking PRs or issues here. - value: | - ### PRs - - - [ ] PR 1 - - ### Issues - - - [ ] Issue 1 - validations: - required: true - - type: textarea - id: pre-release - attributes: - 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). - - [ ] Make sure that all upstream dependencies of this package that need to be submitted to CRAN were accepted before going into release activities. - - [ ] 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 - attributes: - 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`) 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). - - [ ] 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 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. - - ### 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 - 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. - - [ ] Announce the release on ________. - - type: textarea - id: decision-tree - attributes: - label: Decision tree - description: Any decision tree(s) that would aid release management - placeholder: Any decision tree(s) that would aid release management. - value: | - Click [here](https://github.com/insightsengineering/.github/blob/main/.github/ISSUE_TEMPLATE/RELEASE_DECISION_TREE.md) to see the release decision tree. diff --git a/.github/ISSUE_TEMPLATE/cran-release.yml b/.github/ISSUE_TEMPLATE/cran-release.yml index ae49a199..b9144903 100644 --- a/.github/ISSUE_TEMPLATE/cran-release.yml +++ b/.github/ISSUE_TEMPLATE/cran-release.yml @@ -65,6 +65,7 @@ body: 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. diff --git a/.github/ISSUE_TEMPLATE/release.yaml b/.github/ISSUE_TEMPLATE/release.yaml deleted file mode 100644 index 73bb11dc..00000000 --- a/.github/ISSUE_TEMPLATE/release.yaml +++ /dev/null @@ -1,122 +0,0 @@ ---- -name: 🚀 Release -description: Template for package release -title: "[Release]: " -labels: ["release"] -assignees: - - KlaudiaBB - - cicdguy -body: - - type: markdown - attributes: - value: | - ⚠️ Please do not link or mention any internal references in this issue. This includes internal URLs, intellectual property and references. - - type: textarea - id: blocked-by - attributes: - label: Blocked by - description: Any PRs or issues that this release is blocked by. - placeholder: Add a list of blocking PRs or issues here. - value: | - ### PRs - - - [ ] PR 1 - - ### Issues - - - [ ] Issue 1 - validations: - required: true - - type: textarea - id: pre-release - attributes: - 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). - - [ ] 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). - - [ ] Inform about the soft code freeze, decide what gets merged in before starting release activities. - - type: textarea - id: release - attributes: - 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, check README. - - [ ] 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.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 - 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. - - [ ] 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 ________. - - type: textarea - id: decision-tree - attributes: - label: Decision tree - description: Any decision tree(s) that would aid release management - placeholder: Any decision tree(s) that would aid release management. - value: | - Click [here](https://github.com/insightsengineering/.github/blob/main/.github/ISSUE_TEMPLATE/RELEASE_DECISION_TREE.md) to see the release decision tree. diff --git a/.github/ISSUE_TEMPLATE/release.yml b/.github/ISSUE_TEMPLATE/release.yml index f54d69e1..665688e4 100644 --- a/.github/ISSUE_TEMPLATE/release.yml +++ b/.github/ISSUE_TEMPLATE/release.yml @@ -63,11 +63,13 @@ body: 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.