Skip to content

Commit

Permalink
Workflow propagation
Browse files Browse the repository at this point in the history
  • Loading branch information
walkowif committed Dec 11, 2023
1 parent 076d837 commit 1184dfc
Show file tree
Hide file tree
Showing 5 changed files with 64 additions and 46 deletions.
1 change: 1 addition & 0 deletions .Rbuildignore
Original file line number Diff line number Diff line change
Expand Up @@ -44,3 +44,4 @@ coverage.*
^sample_files$
^\.pre-commit-config\.yaml
data-raw/data.R
^pkgdown$
99 changes: 57 additions & 42 deletions .github/ISSUE_TEMPLATE/release.yaml
Original file line number Diff line number Diff line change
Expand Up @@ -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 <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 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 ________.
Expand Down
1 change: 1 addition & 0 deletions .github/workflows/check.yaml
Original file line number Diff line number Diff line change
Expand Up @@ -38,6 +38,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/teal.png
coverage:
Expand Down
1 change: 1 addition & 0 deletions .github/workflows/release.yaml
Original file line number Diff line number Diff line change
Expand Up @@ -52,6 +52,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/teal.png
coverage:
Expand Down
8 changes: 4 additions & 4 deletions .pre-commit-config.yaml
Original file line number Diff line number Diff line change
Expand Up @@ -63,9 +63,9 @@ repos:
.*\.sh|
.*\.svg|
.*\.xml|
(.*/|)\_pkgdown.y[a]ml|
(.*/|)\_pkgdown.y[a]?ml|
(.*/|)\.gitignore|
(.*/|)\.gitlab-ci\.yml|
(.*/|)\.gitlab-ci\.y[a]?ml|
(.*/|)\.lintr|
(.*/|)\.pre-commit-.*|
(.*/|)\.Rbuildignore|
Expand All @@ -75,8 +75,8 @@ repos:
(.*/|)DESCRIPTION|
(.*/|)LICENSE|
(.*/|)NAMESPACE|
(.*/|)staged_dependencies\.yaml|
(.*/|)staged_dependencies\.y[a]?ml|
(.*/|)WORDLIST|
\.github/.*\.yaml|
\.github/.*\.y[a]?ml|
data/.*
)$

0 comments on commit 1184dfc

Please sign in to comment.