-
Notifications
You must be signed in to change notification settings - Fork 38
DX-3003 DX-2971 Workflow Change to One S3 Bucket and CF Test Cleanup #861
Conversation
Test summaryRun details
View run in Cypress Dashboard ➡️ 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 |
Co-authored-by: AJ Rice <53190766+ajrice6713@users.noreply.github.com>
| export const downloadButtonTester = (path) => { | ||
| it('checks the download button to verify it exists',() => { | ||
| cy.visit(`/apis/${path}`) | ||
| cy.visit(`/apis/${path}/`) |
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.
Please explain the trailing slash / updates here and elsewhere - what happens without change(logic in lambda?), what have you tried to resolve it besides this change ?
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.
The /s needed to be updated like this because of the way that the lambda pulls out the subdomain and puts it in the path for the s3 bucket. Without changing this here I was getting errors and a strange URI in the links but this small change makes everything work correctly in the new URL
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.
So can't we put a slash when it's missing at the end of URL in respective lambdas before custom logic?
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 could but it seemed like extra work in there that was unnecessary. Currently lambda is taking the subdomain and adding it in the path as the entrypoint. There's nothing defined to handle the end of any particular URI so there's more logic that would need to thought-through and added to get that piece also working on each call. Since every endpoint needs to be added with or without a slash in our site source code anyway, the simpler solution seems to me to just include it on the paths when we define them instead of adding another manipulation of the URI in the lambda.
That was my thinking at least, if it's more correct/better to define that logic in the lambda and revert these let me know and I'll do that 👍
All spec changes should be done in the api-specs repository.
Please follow the Guide for contributing to our developer documentation.