-
Notifications
You must be signed in to change notification settings - Fork 819
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
ci: smoke test automation #13162
ci: smoke test automation #13162
Conversation
@@ -0,0 +1,22 @@ | |||
|
|||
|
|||
#amplify-do-not-edit-begin |
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.
describe('Smoke Tests', () => { | ||
const createCommands = (amplify: Amplify, directory: string): Command[] => [ | ||
{ | ||
description: `Install @aws-amplify/cli@${cliVersion}`, | ||
run: () => NPM.install(`@aws-amplify/cli@${cliVersion}`, true), | ||
description: 'Amplify CLI version', | ||
run: () => amplify.version(), | ||
}, |
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 moved CLI installation to Actions logic, so that we can reuse same smoke test with many installation strategies.
|
||
$AMPLIFY_PATH status | ||
|
||
ADD_AUTH_REQUEST=$(cat ../.github/actions/run-smoke-tests-windows/add_auth_request.json) |
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.
what path does this script expect to be run from? Could we pass in a base path as an arg to avoid confusion if we change the directory structure of these actions / scripts?
|
||
- name: Install Dependencies | ||
shell: bash | ||
run: yarn install |
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.
should this include --frozen-lockfile
?
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.
bcd0740fa72c:amplify-cli-nofork sobkamil$ yarn install --frozen-lockfile
➤ YN0050: The --frozen-lockfile option is deprecated; use --immutable and/or --immutable-cache instead
I'll add immutable.
|
||
- name: Upload Report | ||
uses: actions/upload-artifact@0b7f8abb1508181956e8e162db84b466c27e18ce #v3.1.2 | ||
if: always() |
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.
is this not the default?
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.
No. By default step is skipped if previous step fails. This makes sure that report is uploaded regardless of test success.
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.
env: | ||
CLI_REGION: ${{ inputs.region }} | ||
CI: true | ||
CIRCLECI: true |
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 is this necessary?
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 is needed to trigger test profile configuration
if (isCI()) { |
@@ -0,0 +1,53 @@ | |||
name: Smoke Tests |
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.
should this be an action rather than a workflow? Seems like it is being dispatched from the canary and manual workflow
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 reason this is "reusable workflow" (see https://docs.github.com/en/actions/using-workflows/reusing-workflows )
Is the matrix
element that runs the same steps on cartesian product of versions and agents.
That's not available in actions.
I created "canary" and "manual" as "lightweight entry points"
Think about smoke-tests.yml
as base class and canary
/manual
as lightweight implementation of base that encapsulate invocation and parameters.
In other words smoke-tests.yml
contains workflow logic. canary
/manual
are just different entry points (like cli throw over programatic interface).
Another reason to have canary
and manual
entry points is that they'll appear as separate top level workflows in GH ui so that person who wants to look at canaries vs person who wants to smoke test RC won't have to reason about modality of parameters.
And yet other reason is that creating single workflow definition with multiple "triggers" would require workarounds to have matrix populated correctly in every case. (Depending on trigger we'd need different logic to populate matrix which is hard problem in declarative yaml).
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 is going to be a huge win!
push: | ||
branches: [smoke-tests-prototype] |
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.
Is this still needed?
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.
no.
uses: ./.github/workflows/smoke-tests.yml | ||
secrets: inherit | ||
with: | ||
versions: '["latest"]' |
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.
Perhaps we should add RC
as well to catch any errors before going to production?
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. I was thinking that RC will go through "oncall will click a button to trigger smoke tests", but having an active monitoring here won't hurt I guess.
@@ -0,0 +1,17 @@ | |||
name: Smoke Tests - Canaries |
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.
What's the notification mechanism for this canary? I.e. how would the oncall find out if a run has failed?
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 is a good question.
Options to pursue:
- (lightweight) Have a slack bot that listens to this workflow, see https://github.blog/changelog/2022-12-06-github-actions-workflow-notifications-in-slack-and-microsoft-teams/ .
- (more involved) Add an action that publishes metric to CloudWatch like our friends did here https://github.com/aws-amplify/amplify-ui/blob/a787311029e6c0c179b552f5abdad1dbed73436a/.github/actions/log-metric/action.yml#L43 .
I'd try that Slack integration first after merging this and explore cloudwatch if this is not working.
call-smoke-tests: | ||
if: github.event_name != 'workflow_dispatch' | ||
uses: ./.github/workflows/smoke-tests.yml | ||
secrets: inherit |
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'm guessing this can be cleaned up as well?
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.
yeah, good catch
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.
Great win!
Description of changes
This PR automates execution of
Smoke Tests
Actions used in workflow that are not defined in this repository:
aws-actions/configure-aws-credentials@04b98b3f9e85f563fb061be8751a0352327246b0 # v3.0.1
- to obtain test account accessruby/setup-ruby@250fcd6a742febb1123a77a841497ccaa8b9e939
- required for Xcode testactions/upload-artifact@0b7f8abb1508181956e8e162db84b466c27e18ce #v3.1.2
- uploads test reportactions/checkout@c85c95e3d7251135ab7dc9ce3241c5835cc595a9 # v3.5.3
Out of scope
The goal of this PR is to :
Remaining coverage (proper Windows tests and Amplify App) will be pursued in subsequent PRs.
Issue #, if available
Description of how you validated changes
Running workflow from
push to smoke-tests-prototype
branch.See https://github.com/aws-amplify/amplify-cli/actions/workflows/smoke-tests-manual.yml
Other triggers like schedule and manual dispatch will be tested after merge (they require workflow to be present in
dev
branch).E2E test run as well (since I touched these)
Checklist
yarn test
passesBy submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.