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

feat: Update migration for projects with projectId #21193

Conversation

estrada9166
Copy link
Member

@estrada9166 estrada9166 commented Apr 26, 2022

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

  • Have tests been added/updated?
  • Has the original issue (or this PR, if no issue exists) been tagged with a release in ZenHub? (user-facing changes only)
  • Has a PR for user-facing changes been opened in cypress-documentation?
  • Have API changes been updated in the type definitions?
  • Have new configuration options been added to the cypress.schema.json?

@cypress-bot
Copy link
Contributor

cypress-bot bot commented Apr 26, 2022

Thanks for taking the time to open a PR!

@cypress
Copy link

cypress bot commented Apr 26, 2022



Test summary

17907 0 217 0Flakiness 2


Run details

Project cypress
Status Passed
Commit 428abdd
Started May 3, 2022 10:32 PM
Ended May 3, 2022 10:47 PM
Duration 14:55 💡
OS Linux Debian - 10.10
Browser Multiple

View run in Cypress Dashboard ➡️


Flakiness

files.cy.js Flakiness
1 ... > has implicit existence assertion, retries and throws a specific error when file does not exist for null encoding
navigation.cy.js Flakiness
1 src/cy/commands/navigation > #visit > window immediately resolves and doesn't reload when visiting the same URL with hashes

This 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

@estrada9166 estrada9166 marked this pull request as ready for review April 27, 2022 16:34
@estrada9166 estrada9166 requested review from a team and tgriesser as code owners April 27, 2022 16:34
@estrada9166 estrada9166 requested review from jennifer-shehane, a team and lmiller1990 and removed request for a team and jennifer-shehane April 27, 2022 16:35
Copy link
Contributor

@lmiller1990 lmiller1990 left a 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
Copy link
Contributor

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.

Copy link
Member

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

Copy link
Contributor

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.

Copy link
Member Author

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

Copy link
Contributor

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?

Copy link
Member Author

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 () {
Copy link
Contributor

Choose a reason for hiding this comment

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

Copy link
Contributor

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', () => {
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
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.
Copy link
Contributor

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.

@MuazOthman MuazOthman requested a review from flotwig April 29, 2022 15:35
Copy link
Contributor

@lmiller1990 lmiller1990 left a 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,
}
Copy link
Contributor

Choose a reason for hiding this comment

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

Copy link
Member Author

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

…jandro/feat/do-not-migrate-preExtension-if-projectId-exist
@estrada9166 estrada9166 merged commit 88ef75c into 10.0-release May 3, 2022
@estrada9166 estrada9166 deleted the alejandro/feat/do-not-migrate-preExtension-if-projectId-exist branch May 3, 2022 22:48
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.

4 participants