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

chore(testinfra): initial ami test #746

Merged
merged 2 commits into from
Oct 19, 2023
Merged

chore(testinfra): initial ami test #746

merged 2 commits into from
Oct 19, 2023

Conversation

soedirgo
Copy link
Member

@soedirgo soedirgo commented Oct 4, 2023

Initial Testinfra integration tests for AMI builds.

TODO:

  • allow GHA AWS role to run instances
  • add steps for locally running tests

@soedirgo soedirgo changed the title Bs/testinfra ami chore(testinfra): initial ami test Oct 4, 2023
@soedirgo soedirgo force-pushed the bs/testinfra-ami branch 2 times, most recently from aac3052 to 8619064 Compare October 5, 2023 09:19
from ec2instanceconnectcli.EC2InstanceConnectKey import EC2InstanceConnectKey
from time import sleep

postgresql_schema_sql_content = """
Copy link
Member Author

Choose a reason for hiding this comment

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

We need to hardcode a lot of these since the setup logic lives in worker. This makes the tests brittle. One possible improvement would be to move some of the setup logic into AMI creation.

Copy link
Contributor

Choose a reason for hiding this comment

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

The bulk of the content here is dependent on project specific data that'll only be available in the worker, no?

The improvements to be made here are in making the interface between the AMI and the worker more explicit, and testing on both sides (that the worker produces the right interface, and that the AMI here takes that interface and does the right things with it).

Copy link
Contributor

Choose a reason for hiding this comment

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

To start with, we can add a note in the relevant spots on both sides that any change to one (worker config generation/postgres integration test) must be captured by an update and ideally a test in the other

Copy link
Member Author

Choose a reason for hiding this comment

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

Yeah, what I mean is to move the file templating to supabase/postgres, so that UserData only contains things that need to be variable. I'll start with adding a note for now.

@soedirgo soedirgo marked this pull request as ready for review October 5, 2023 09:42
@soedirgo soedirgo requested a review from a team as a code owner October 5, 2023 09:42
@soedirgo soedirgo marked this pull request as draft October 5, 2023 09:46
@soedirgo soedirgo marked this pull request as ready for review October 5, 2023 09:49
Copy link
Contributor

@darora darora left a comment

Choose a reason for hiding this comment

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

Looks like a good start! Are you planning to add the rest of the testing scenarios as well? Or would you want someone on infra to take over and spec the rest out?

from ec2instanceconnectcli.EC2InstanceConnectKey import EC2InstanceConnectKey
from time import sleep

postgresql_schema_sql_content = """
Copy link
Contributor

Choose a reason for hiding this comment

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

The bulk of the content here is dependent on project specific data that'll only be available in the worker, no?

The improvements to be made here are in making the interface between the AMI and the worker more explicit, and testing on both sides (that the worker produces the right interface, and that the AMI here takes that interface and does the right things with it).

from ec2instanceconnectcli.EC2InstanceConnectKey import EC2InstanceConnectKey
from time import sleep

postgresql_schema_sql_content = """
Copy link
Contributor

Choose a reason for hiding this comment

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

To start with, we can add a note in the relevant spots on both sides that any change to one (worker config generation/postgres integration test) must be captured by an update and ideally a test in the other

ec2 = boto3.resource("ec2", region_name="ap-southeast-1")
images = list(
ec2.images.filter(
Filters=[{"Name": "name", "Values": ["supabase-postgres-ci-ami-test"]}]
Copy link
Contributor

Choose a reason for hiding this comment

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

We should be using the version string from the common.vars file here, yeah? Not sure which AMI this is currently set up to use?

Copy link
Member Author

Choose a reason for hiding this comment

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

The test run will always publish an AMI with AMI name supabase-postgres-ci-ami-test. Subsequent runs will deregister older AMIs through the force_deregister option.

One alternative I haven't explored is to move the test run into a Packer provisioning step, that way we might not even need to publish the AMI. Can be done as a follow up.

@soedirgo
Copy link
Member Author

I think it's better for the infra team to take over, since you have a better understanding of the requirements.

Comment on lines +125 to +134
- name: Run tests
run: |
# TODO: use poetry for pkg mgmt
pip3 install boto3 boto3-stubs[essential] docker ec2instanceconnectcli pytest pytest-testinfra[paramiko,docker] requests
pytest -vv testinfra/test_ami.py

- name: Cleanup resources on build cancellation
if: ${{ cancelled() }}
run: |
aws ec2 --region ap-southeast-1 describe-instances --filters "Name=tag:packerExecutionId,Values=${GITHUB_RUN_ID}" --query "Reservations[].Instances[].InstanceId" --output text | xargs -I {} aws ec2 terminate-instances --instance-ids {}
Copy link
Contributor

Choose a reason for hiding this comment

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

since the setup to this point is the same as ami-release could we add these lines to that file instead & run it on PR to reduce duplication?

@soedirgo
Copy link
Member Author

Merging this for now - will dedupe some of the Action steps in another PR

@soedirgo soedirgo force-pushed the bs/testinfra-ami branch 6 times, most recently from e802ea1 to 78a8d26 Compare October 19, 2023 13:44
@soedirgo soedirgo merged commit b6560e1 into develop Oct 19, 2023
@soedirgo soedirgo deleted the bs/testinfra-ami branch October 19, 2023 13:57
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.

3 participants