Run e2e tests on each PR.

[purple4reina]

What does this PR do?

Run the serverless-e2e-tests on PR, skipping anything that isn't a python test. First publishes the layer build to sandbox account region us-west-2. Then, after gathering the arn for the new layer, pass that to the e2e tests for testing.

Motivation

Better to get alerted right away to potential e2e bugs.

Testing Guidelines

Additional Notes

Because this job is triggering job in a different repo, it is quite tough to access the results of that downstream job. As designed right now, a e2e-status job will be created in addition to the e2e-test job. This status job runs only after the e2e-test job completes. The reason this status job is necessary is so that we can post the results back to github.

The problem with this is the e2e-status job can take hours to fully complete. That's because not only do all the other tests in this repo need to run (integration, unit, layer size, etc), it also needs to run the e2e tests, and it must also wait for the full teardown of aws resources. The latter is what can take so long because these teardown jobs are set to run after a 2 hour delay. So, we technically aren't able to get results posted back to github until all of that completes.

The work around, which was too hard to implement with the time I had, is to use the gitlab api to poll the status of the e2e-test job. This might involve creating a Project Token which is more work that I think it's worth.

An alternative solution is to set the e2e-status test as required by github. There are some major problems with this though. There are times in which we would expect that the e2e tests would fail. For example, if I'm implementing a new feature which will turn an e2e test from not working to working, then the e2e tests themselves will always fail in that case, which is what we want. To get around that, we could remove the xfail strict requirement on the e2e tests downstream. But this would mean we aren't able to keep our feature parity doc in lock step with reality.

At this point, I think the best thing to do is to mark the e2e-status job as required. We are always able to override these failures in the UI, which shouldn't mean we're moving any slower.

Types of Changes

• Bug fix
• New feature
• Breaking change
• Misc (docs, refactoring, dependency upgrade, etc.)

Check all that apply

• This PR's description is comprehensive
• This PR contains breaking changes that are documented in the description
• This PR introduces new APIs or parameters that are documented and unlikely to change in the foreseeable future
• This PR impacts documentation, and it has been updated (or a ticket has been logged)
• This PR's changes are covered by the automated tests
• This PR collects user input/sensitive content into Datadog
• This PR passes the integration tests (ask a Datadog member to run the tests)

https://datadoghq.atlassian.net/browse/APMSVLS-20