Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

chore(ci): run multiple versions of stencil #199

Merged
merged 1 commit into from
Jan 17, 2023

Conversation

rwaskiewicz
Copy link
Member

@rwaskiewicz rwaskiewicz commented Jan 12, 2023

Pull request checklist

Please check if your PR fulfills the following requirements:

  • Docs have been reviewed and added / updated if needed (for bug fixes / features)
  • Build (npm run build) was run locally and any changes were pushed
  • Tests (npm test) were run locally and passed
  • Prettier (npm run prettier) was run locally and passed

Pull request type

Please check the type of change your PR introduces:

  • Bugfix
  • Feature
  • Refactoring (no functional changes, no api changes)
  • Build related changes
  • Documentation content changes
  • Other (please describe):

What is the current behavior?

CI only runs on the version of Stencil that is declared in package-lock.json

GitHub Issue Number: N/A

What is the new behavior?

this commit updates our ci workflow to run the build and test steps against multiple versions of stencil. the motivating factors behind this change are as follows:

  1. we're preparing to release stencil v3, and would like to catch any regresssions in the library prior to release
  2. this library will simultanesouly support stencil v2 and v3 for a period of time, and would like to have ci run on both following the stencil v3.0.0 release

in pursuit of those goals, four versions of stencil are tested:

  1. DEFAULT - uses the version of Stencil written in package-lock.json, keeping the same version used by the Stencil team as a source of truth
  2. 2 - will install the latest release under major version 2 of Stencil. This should be kept as long as this library supports Stencil v2.Y.Z
  3. v3-next - will install a pre-release version of Stencil v3, and is used to detect any regressions in a pre-release of v3.0.0.
  4. latest - will install the latest version of Stencil. Prior to the Stencil v3.0.0 release, this will resolve to the latest version of Stencil v2. After the Stencil v3.0.0 release, it will resolve to the latest version of Stencil v3.

this allows the team to have full coverage with regards to testing now (prior to the stencil v3 release) where at the time of this writing:

  1. DEFAULT - resolves to Stencil v2.21.0
  2. 2 - resolves to Stencil v2.21.0
  3. v3-next - resolves to Stencil v3.0.0-beta.1
  4. latest - resolves to Stencil v2.21.0

following the stencil v3.0.0 release, the same versions will resolve as follows (without the team having to swoop in and change ci as a part of the v3 release process):

  1. DEFAULT - resolves to Stencil v2.21.0 (and will require a code change post release, but not immediately due to other version tags)
  2. 2 - resolves to the latest version of Stencil v2.Y.Z
  3. v3-next - resolves to the last Stencil v3 pre-release (and can be removed at the team's leisure)
  4. latest - will install the latest version of Stencil v3.Y.Z

this change will require code clean up (removing DEFAULT, v3-next). however, the value add here is that said change can happen any time following the stencil v3 release, and keeps the ci workflow resilient to unknown changes that may occur in the v2 and v3 branches of stencil core

Does this introduce a breaking change?

  • Yes
  • No

Testing

Tailed the results of this Action running, verifying that:

  • For 'DEFAULT', no new version of Stencil is installed (the new install command is skipped)
  • For other versions, the correct version of Stencil is installed (verifiable via the 'Report Stencil Version' step

Other information

If we land this as-is, I'll need to update the CI checks accordingly (it's still assuming a single 'build' check to run)

# 4. latest - will install the latest version of Stencil. Prior to the Stencil v3.0.0 release, this will
# resolve to the latest version of Stencil v2. After the Stencil v3.0.0 release, it will resolve to the latest
# version of Stencil v3.
stencil_version: ['DEFAULT', '2', 'v3-next', 'latest']
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As stated in the PR summary, I expect 'DEFAULT' and 'v3-next' to be removed some time after the v3 release of Stencil

@rwaskiewicz rwaskiewicz marked this pull request as ready for review January 12, 2023 13:22
@rwaskiewicz rwaskiewicz requested a review from a team as a code owner January 12, 2023 13:22
Copy link
Member

@tanner-reits tanner-reits left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good. Do we have/need a task to come back to remove those versions at some point? Or maybe call it out in the v3 release plan "post release" section

Copy link
Member

@alicewriteswrongs alicewriteswrongs left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm!

@rwaskiewicz
Copy link
Member Author

Looks good. Do we have/need a task to come back to remove those versions at some point? Or maybe call it out in the v3 release plan "post release" section

@tanner-reits added to the post-release section of the Notion doc

this commit updates our ci workflow to run the build and test steps
against multiple versions of stencil. the motivating factors behind this
change are as follows:
1. we're preparing to release stencil v3, and would like to catch any
   regresssions in the library prior to release
2. this library will simultanesouly support stencil v2 and v3 for a
   period of time, and would like to have ci run on both following the
   stencil v3.0.0 release

in pursuit of those goals, four versions of stencil are tested:
1. DEFAULT - uses the version of Stencil written in `package-lock.json`,
  keeping the same version used by the Stencil team as a source of truth
2. 2 - will install the latest release under major version 2 of Stencil.
   This should be kept as long as this library supports Stencil v2.Y.Z
3. v3-next - will install a pre-release version of Stencil v3, and is
   used to detect any regressions in a pre-release of v3.0.0.
4. latest - will install the latest version of Stencil. Prior to the
   Stencil v3.0.0 release, this will resolve to the latest version of
   Stencil v2. After the Stencil v3.0.0 release, it will resolve to the
   latest version of Stencil v3.

this allows the team to have full coverage with regards to testing now
(prior to the stencil v3 release) where at the time of this writing:
1. DEFAULT - resolves to Stencil v2.21.0
2. 2 - resolves to Stencil v2.21.0
3. v3-next - resolves to Stencil v3.0.0-beta.1
4. latest - resolves to Stencil v2.21.0

following the stencil v3.0.0 release, the same versions will resolve as
follows (without the team having to swoop in and change ci as a part of
the v3 release process):
1. DEFAULT - resolves to Stencil v2.21.0 (and will require a code
   change post release, but not immediately due to other version tags)
2. 2 - resolves to the latest version of Stencil v2.Y.Z
3. v3-next - resolves to the last Stencil v3 pre-release (and can be
   removed at the team's leisure)
4. latest - will install the latest version of Stencil v3.Y.Z

this change will require code clean up (removing DEFAULT, v3-next).
however, the value add here is that said change can happen any time
following the stencil v3 release, and keeps the ci workflow resilient to
unknown changes that may occur in the v2 and v3 branches of stencil core
@rwaskiewicz rwaskiewicz force-pushed the rwaskiewicz/gha-test-many-stencil-versions branch from b10a7b8 to 1d403aa Compare January 17, 2023 21:34
@rwaskiewicz rwaskiewicz merged commit d9ae61a into main Jan 17, 2023
@rwaskiewicz rwaskiewicz deleted the rwaskiewicz/gha-test-many-stencil-versions branch January 17, 2023 21:36
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants