-
Notifications
You must be signed in to change notification settings - Fork 3.2k
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
feat: Update migration for projects with projectId #21193
feat: Update migration for projects with projectId #21193
Conversation
Thanks for taking the time to open a PR!
|
Test summaryRun details
View run in Cypress Dashboard ➡️ FlakinessThis comment has been generated by cypress-bot as a result of this project's GitHub integration settings. You can manage this integration in this project's settings in the Cypress Dashboard |
…ension-if-projectId-exist
…ension-if-projectId-exist
…-exist' of github.com:cypress-io/cypress into alejandro/feat/do-not-migrate-preExtension-if-projectId-exist
…jandro/feat/do-not-migrate-preExtension-if-projectId-exist
…ension-if-projectId-exist
…ension-if-projectId-exist
…ension-if-projectId-exist
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.
Some questions, code looks pretty thorough.
@@ -62,6 +62,18 @@ export class MigrationDataSource { | |||
return this.ctx.coreData.migration.legacyConfigForMigration | |||
} | |||
|
|||
get shouldMigratePreExtension () { | |||
return !this.legacyConfig.projectId |
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.
I wonder if anyone does nested projectId, like
{
"e2e": {
"projectId": "ABC"
},
"component": {
"projectId": "DEF"
}
}
Not sure if this is even valid, but if it is, we might need to consider this scenario, too.
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.
According to Brian, this should not be permitted, it needs to be a root level property only
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.
We might need to verify if this actually works in 9.x and see if anyone was using it like that, seems unlikely but you never know.
Eg: I'm saying if it was previously permitted, it's possible someone thought to do this.
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.
I tried the projectId inside the e2e and it works fine in 9.x
The support for this should be something like return !this.legacyConfig.projectId && !this.legacyConfig.e2e?.projectId
- how common may this be? I guess it would be safer to support it
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.
That means component.projectId
probably works, too. If someone either e2e.projectId
OR component.projectId
, I think we should not rename, just to be safe.
I have no idea how common this is, but since this is how we make $$$ I don't think we can just assume it's unlikely to happen - we need to get this 100% perfect. I think we should do as you suggested, and also add a check for component.projectId
to be 100% safe. Thoughts?
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.
For the moment we are not gonna take into account the CT for the history on the cloud - just the E2E tests; that's why I only update the e2e.projectId
return !this.legacyConfig.projectId | ||
} | ||
|
||
get migrationOptions () { |
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.
Seems like we have this twice, here and also here? https://github.com/cypress-io/cypress/pull/21193/files#diff-c2c1f114b54072e7f036c272e41454586ddba1378ada7bf61d38049e05e3d8f5R68
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.
Also what is the point of this getter? Why not just access shouldMigratePreExtension
directly?
@@ -19,13 +19,27 @@ describe('formatMigrationFile', () => { | |||
{ text: 'js', highlight: false }, | |||
]) | |||
}) | |||
|
|||
it('do not highlight the preExtension', () => { |
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.
it('do not highlight the preExtension', () => { | |
it('do not highlight the preExtension when migratePreExtension is false', () => { |
@@ -0,0 +1,35 @@ | |||
## Migration E2E Custom Integration with projectId | |||
|
|||
An e2e project with a custom `integrationFolder` named `src` and projectId. It uses the default `testFiles`. We will keep the custom `intergrationFolder`, but it'll be part of `e2e.specPattern`. We will rename their specs to use the `.cy.js` extension. |
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.
Don't forget to update this to explain this fixture - it says "We will rename their specs to use the .cy.js
extension", which isn't right.
In this case, "this project has as projectId
which means we do not migrate to the new .cy.js
extension, because this will interfere with the historical data on Cypress Cloud" or something like that.
…ension-if-projectId-exist
…ension-if-projectId-exist
…ension-if-projectId-exist
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.
One more comment, but not a blocker.
// If the configFile has projectId, we do not want to change the preExtension | ||
// so, we can keep the cloud history | ||
shouldMigratePreExtension: !config.projectId && !config.e2e?.projectId, | ||
} |
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.
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.
This file lives on the data-context
folder but is not using the dataContext
itself - I'll call this a util/helper file
…ension-if-projectId-exist
…ension-if-projectId-exist
…jandro/feat/do-not-migrate-preExtension-if-projectId-exist
User facing changelog
Additional details
How has the user experience changed?
Do not migrate the user pre-extension if the project has projected on the config, with this change we are not going to display anything related to the pre-extension migration, and also, we are gonna add a custom specPattern in the config file.
The reason behind this change is to keep the spec history on the cloud, simple as possible.
PR Tasks
cypress-documentation
?type definitions
?cypress.schema.json
?