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

test: add deploy test #891

Closed

Conversation

0618
Copy link
Contributor

@0618 0618 commented Jan 9, 2024

Problem

  • add e2e-flow test, which is a copy of test-e2e/create-amplify.test
  • add deploy test to create-amplify script
  • make the deploy test work

Issue number, if available:

Changes

Corresponding docs PR, if applicable:

Validation

Checklist

  • If this PR includes a functional change to the runtime behavior of the code, I have added or updated automated test coverage for this change.
  • If this PR requires a change to the Project Architecture README, I have included that update in this PR.
  • If this PR requires a docs update, I have linked to that docs PR above.
  • If this PR modifies E2E tests, makes changes to resource provisioning, or makes SDK calls, I have run the PR checks with the run-e2e label set.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

Copy link

changeset-bot bot commented Jan 9, 2024

⚠️ No Changeset found

Latest commit: 212c8c1

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

Copy link
Member

@sobolk sobolk left a comment

Choose a reason for hiding this comment

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

I do like an idea to just craft separate test for this. But perhaps we could then reuse what we run in canary workflow. (see comment).

shell: bash
run: |
PACKAGE_MANAGER_EXECUTABLE=${{matrix.pkg-manager}} npm run test:dir packages/integration-tests/src/test-e2e/create_amplify.test.ts
PACKAGE_MANAGER_EXECUTABLE=${{matrix.pkg-manager}} npm run test:dir packages/integration-tests/src/e2e-flow/e2e_flow.test.ts
Copy link
Member

Choose a reason for hiding this comment

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

If we're going for separate test file in separate dir (i.e. not included in e2e run)
then perhaps we could just use this one https://github.com/aws-amplify/amplify-backend/blob/main/packages/integration-tests/src/test-live-dependency-health-checks/health_checks.test.ts
but adapt it to take package manager as input.

import { testConcurrencyLevel } from '../test-e2e/test_concurrency.js';
import { e2eToolingClientConfig } from '../e2e_tooling_client_config.js';

type PackageManagerExecutable = 'npm' | 'yarn-classic' | 'yarn-modern' | 'pnpm';
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
type PackageManagerExecutable = 'npm' | 'yarn-classic' | 'yarn-modern' | 'pnpm';
type PackageManager = 'npm' | 'yarn-classic' | 'yarn-modern' | 'pnpm';

This is not an executable. We derive executable from this enumeration later.

Comment on lines +22 to +33
const concurrency = process.env.PACKAGE_MANAGER_EXECUTABLE?.startsWith('yarn')
? 1
: testConcurrencyLevel;

const packageManagerSetup = async (
packageManagerExecutable: PackageManagerExecutable,
dir?: string
) => {
const execaOptions = {
cwd: dir || os.homedir(),
stdio: 'inherit' as const,
};
Copy link
Member

Choose a reason for hiding this comment

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

Could we refactor the code in such a way that process.env.PACKAGE_MANAGER_EXECUTABLE is read only once somewhere?

Options:

  1. Do that in packageManagerSetup and have packageManagerSetup return a type that provides all what test needs for further execution i.e. type PackageManagerTestConfiguration = { executable: string; maxConcurrency?: number }
  2. Create TestPackageManagerControllerFactory and have TestPackageManagerController and subclasses (like we did in create amplify) to encapsulate functionalities.

(I think 1. is good enough for tests).

Also. If this stays as packageManagerSetup then it should be renamed to setupPackageManager and perhaps live in its own file given volume.

Comment on lines +80 to +83
const { PACKAGE_MANAGER_EXECUTABLE = 'npm' } = process.env;
const packageManagerExecutable = PACKAGE_MANAGER_EXECUTABLE.startsWith('yarn')
? 'yarn'
: PACKAGE_MANAGER_EXECUTABLE;
Copy link
Member

Choose a reason for hiding this comment

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

this part should be in packageManagerSetup (see also the other comment)

Comment on lines +90 to +104
// install package manager
if (PACKAGE_MANAGER_EXECUTABLE === 'yarn-classic') {
await execa('npm', ['install', '-g', 'yarn'], { stdio: 'inherit' });
} else if (PACKAGE_MANAGER_EXECUTABLE === 'pnpm') {
await execa('npm', ['install', '-g', PACKAGE_MANAGER_EXECUTABLE], {
stdio: 'inherit',
});
}

// nuke the npx cache to ensure we are installing packages from the npm proxy
if (PACKAGE_MANAGER_EXECUTABLE !== 'yarn-modern') {
await packageManagerSetup(
PACKAGE_MANAGER_EXECUTABLE as PackageManagerExecutable
);
}
Copy link
Member

Choose a reason for hiding this comment

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

this too should be part of setup package manager.

Comment on lines +132 to +135
const initialStates = ['empty', 'module', 'commonjs'] as const;

initialStates.forEach((initialState) => {
void describe('installs expected packages and scaffolds expected files', () => {
Copy link
Member

Choose a reason for hiding this comment

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

we shouldn't repeat tests from create amplify if we're creating new file.
i.e. we should start with single test that does full create-amplify -> deployment flow here.

which means that we should:

  1. remove initialStates, and just start from empty
  2. remove most of assertions that repeat create amplify test, i.e. it should be similar to https://github.com/aws-amplify/amplify-backend/blob/main/packages/integration-tests/src/test-live-dependency-health-checks/health_checks.test.ts

Copy link
Contributor Author

@0618 0618 Jan 11, 2024

Choose a reason for hiding this comment

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

done 1. 8dfe98f

});
});

void describe('fails fast', () => {
Copy link
Member

Choose a reason for hiding this comment

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

we can remove this block too if we're testing in separate file.

Copy link
Contributor Author

@0618 0618 Jan 11, 2024

Choose a reason for hiding this comment

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

Removed 8dfe98f

@0618 0618 mentioned this pull request Jan 10, 2024
5 tasks
@0618
Copy link
Contributor Author

0618 commented Jan 10, 2024

Continue on #901

@0618 0618 closed this Jan 10, 2024
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.

2 participants