-
Notifications
You must be signed in to change notification settings - Fork 4k
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(cli): move integ tests to @aws-cdk-testing/cli-integ #23590
Conversation
Clean up the CLI integration tests a bit, by moving them to a separate package. This has the following benefits: - More clearly isolates the tests and keeps them separate from the CLI package proper. - Allows normal specification of dependencies of the integration tests themselves, via a proper `package.json` and Yarn lockfile. - Makes it more clear what reusable files are part of the CLI, vs what reusable files are part of the integration tests. - Makes it more clear/easier to download an old copy of the tests. Also makes the following improvement: - Publishes the test artifacts to CodeArtifact, so that we don't need to do crazy shell hijacking shenanigans in order to fake NPM/Maven/NuGet/PyPI repositories from a set of artifacts. This is not the final form of our testing infrastructure. Right now, a fresh CodeArtifact repo is created for every test with all packages in it. In an actual pipeline, we would be better off publishing to a CodeArtifact repo once and all tests pulling from that. That will be forthcoming in the future.
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 pull request linter has failed. See the aws-cdk-automation comment below for failure reasons. If you believe this pull request should receive an exemption, please comment and provide a justification.
✅ Updated pull request passes all PRLinter validations. Dissmissing previous PRLinter review.
Started build 516cbb73-c36b-4826-9bee-f5e695df708d |
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.
None of the questions or comments I have are blocking.
This is a non-trivial amount of files changed, for as far as I can tell, things look good.
Added do-not-merge
label.
* Download the current `@aws-cdk-testing/cli-integ` artifact at `V1`. | ||
* Determine the previous version `V0` (use `query-github` for this). | ||
* Download the previous `@aws-cdk-testing/cli-integ` artifact at `V0`. | ||
* From the `V1` artifact, apply the `V0` patch set. | ||
* Run the `V0` tests with the `--framework-version` option: |
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.
[nit] Perhaps prev
/ old
or current
/new
could be more explicit.
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 thought about it and I prefer this because it puts you in mind of version numbers.
// this returns a list in descending order, newest releases first | ||
// opts for same major version where possible, falling back otherwise | ||
// to previous major versions. |
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.
[non-blocking] Is there any chance of a release timing forking up functionality?
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.
Probably.
* | ||
* If no such value is currently available, wait until it is. | ||
*/ | ||
public async take(): Promise<ILease<A>> { |
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.
[non-blocking] Does this have to be public?
Will a consumer ever try to acquire a lease with any other purpose than executing a block?
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 like the dual API.
}); | ||
} | ||
|
||
export async function writeMavenSettingsFile(filename: string, login: LoginInformation) { |
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.
[high number of file changes, I might just have scrolled past] The "filename" (usageDir
) should be removed in a cleanup()
, right/ does 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.
usageDir
is (may be) cleaned up in a separate invocation. The CLI also has two possible APIs:
publish
+clean
; orrun <cmd>
return XpMutexPool.fromDirectory(path.join(os.tmpdir(), name)); | ||
} | ||
|
||
private readonly queuedResolvers = new Set<() => void>(); |
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.
Why a Set
and not a Queue
(based on name and the FIFO comment from a previous file)?
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.
Hm. There are definitely no FIFO guarantees. Where did you read that?
|
||
jest.setTimeout(600_000); | ||
jest.setTimeout(60 * 60_000); // Includes the time to acquire locks |
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.
[non-blocking] If something starts to edge-case, how can we quickly tell we're hitting that scenario?
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'll see timeouts
@@ -1,5 +1,4 @@ | |||
import { withMonolithicCfnIncludeCdkApp } from '../helpers/cdk'; | |||
import { integTest } from '../helpers/test-helpers'; | |||
import { integTest, withMonolithicCfnIncludeCdkApp } from '../../lib'; | |||
|
|||
jest.setTimeout(600_000); |
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.
Does this need updating 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.
Nah, it's only 1 test here
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
Thank you for contributing! Your pull request will be updated from main and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork). |
#31131) ### Reason for this change The cli integration tests cannot use your local version of `aws-cdk-lib`. This can be verified by making your `Stack` construct throw an error upon creation, and watching no CLI integration tests fail, even with `-a`. ### Description of changes Fixed the CLI integration test framework to correctly link the local packages, like it [used to](#23590). ### Description of how you validated changes Manual testing. This isn't something we can add automated tests for. ### Checklist - [x] My code adheres to the [CONTRIBUTING GUIDE](https://github.com/aws/aws-cdk/blob/main/CONTRIBUTING.md) and [DESIGN GUIDELINES](https://github.com/aws/aws-cdk/blob/main/docs/DESIGN_GUIDELINES.md) ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
aws#31131) ### Reason for this change The cli integration tests cannot use your local version of `aws-cdk-lib`. This can be verified by making your `Stack` construct throw an error upon creation, and watching no CLI integration tests fail, even with `-a`. ### Description of changes Fixed the CLI integration test framework to correctly link the local packages, like it [used to](aws#23590). ### Description of how you validated changes Manual testing. This isn't something we can add automated tests for. ### Checklist - [x] My code adheres to the [CONTRIBUTING GUIDE](https://github.com/aws/aws-cdk/blob/main/CONTRIBUTING.md) and [DESIGN GUIDELINES](https://github.com/aws/aws-cdk/blob/main/docs/DESIGN_GUIDELINES.md) ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
…k (#31131) ### Reason for this change The cli integration tests cannot use your local version of `aws-cdk-lib`. This can be verified by making your `Stack` construct throw an error upon creation, and watching no CLI integration tests fail, even with `-a`. ### Description of changes Fixed the CLI integration test framework to correctly link the local packages, like it [used to](aws/aws-cdk#23590). ### Description of how you validated changes Manual testing. This isn't something we can add automated tests for. ### Checklist - [x] My code adheres to the [CONTRIBUTING GUIDE](https://github.com/aws/aws-cdk/blob/main/CONTRIBUTING.md) and [DESIGN GUIDELINES](https://github.com/aws/aws-cdk/blob/main/docs/DESIGN_GUIDELINES.md) ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
Clean up the CLI integration tests a bit, by moving them to a separate TypeScript package. This has the following benefits:
package.json
and Yarn lockfile.bash
are now written in TypeScript+Jest, making them easier to maintain.Also makes the following changes:
2.3.4
, the candidate build versions would be2.4.0-rc.0
and2.4.0-alpha.0
.2.4.0
actually released, its alpha packages would also be numbered2.4.0-alpha.0
.2.4.0-alpha.999
.This is not the final form of our testing infrastructure. Right now, a fresh CodeArtifact repo is created for every test with all packages in it. In an actual pipeline, we would be better off publishing to a CodeArtifact repo once and all tests pulling from that.
That will be forthcoming in the future.
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license