-
Notifications
You must be signed in to change notification settings - Fork 24
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
Conversation
# 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'] |
There was a problem hiding this comment.
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
There was a problem hiding this 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
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm!
@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
b10a7b8
to
1d403aa
Compare
Pull request checklist
Please check if your PR fulfills the following requirements:
npm run build
) was run locally and any changes were pushednpm test
) were run locally and passednpm run prettier
) was run locally and passedPull request type
Please check the type of change your PR introduces:
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:
in pursuit of those goals, four versions of stencil are tested:
package-lock.json
, keeping the same version used by the Stencil team as a source of truththis 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:
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):
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?
Testing
Tailed the results of this Action running, verifying that:
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)