-
-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Merge remote-tracking branch 'origin/main' into 643-ael02-spec-added@…
…main
- Loading branch information
Showing
55 changed files
with
1,249 additions
and
256 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -10,4 +10,6 @@ docs | |
| ^.gitlab-ci.yml | ||
| CODE_OF_CONDUCT.md | ||
| SECURITY.md | ||
| LICENSE | ||
| data-raw/* | ||
| ^pkgdown$ | ||
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,124 @@ | ||
| --- | ||
| name: 🎉 CRAN Release | ||
| description: Template for release to CRAN | ||
| title: "[Release]: <version>" | ||
| 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 <files your modified> | ||
| # Commit the changes | ||
| git commit -m "[skip vbump] <Your commit message>" | ||
| 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<iteration-number> (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<iteration number> | ||
| git push origin vX.Y.Z-rc<iteration number>` | ||
| - [ ] 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 <commit hash>` | ||
| 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. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,122 @@ | ||
| --- | ||
| name: 🚀 Release | ||
| description: Template for package release | ||
| title: "[Release]: <version>" | ||
| 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 <files your modified> | ||
| # Commit the changes | ||
| git commit -m "[skip vbump] <Your commit message>" | ||
| 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<iteration-number> (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<iteration number> | ||
| git push origin vX.Y.Z-rc<iteration number>` | ||
| - [ ] 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 <commit hash>` | ||
| 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. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1 +1 @@ | ||
| linters: with_defaults(line_length_linter = line_length_linter(120), object_usage_linter = NULL, object_name_linter = NULL, cyclocomp_linter = cyclocomp_linter(complexity_limit = 25L)) | ||
| linters: linters_with_defaults(line_length_linter = line_length_linter(120), object_usage_linter = NULL, object_name_linter = NULL, cyclocomp_linter = cyclocomp_linter(complexity_limit = 25L)) |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.