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
Simpler Cypress Setup #150
Conversation
- run: pipx install pipenv | ||
- uses: actions/setup-python@v2 | ||
with: | ||
python-version: '3.10' | ||
cache: 'pipenv' | ||
# Can't use cache because of https://github.com/actions/cache/issues/319 | ||
# cache: 'pipenv' |
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.
caching doesn't work for deployment_status
events sadly. (known bug)
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 a big deal at the moment ? No right our apps arent that big that it would mean a huge slow down?
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.
It's not really a big deal but it will add time to the test running. So if you push one final commit to the bootstrapper you'll need to wait an extra minute or so.
This does NOT impact the generated projects so definitely not a huge deal in my mind.
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.
ahhh okay good call out!
@@ -64,7 +37,7 @@ jobs: | |||
NPM_CONFIG_PRODUCTION: false | |||
working-directory: ./my_project/client | |||
run: npm install | |||
- name: Run against ${{ needs.Setup.outputs.BASE_URL }} | |||
- name: Run against ${{ github.event.deployment_status.environment_url }} |
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.
Removed the jwalton/gh-find-current-pr@v1
action dependency as we no longer need to "figure out" what the URL is for the deployment. Heroku gives that to as when it creates the status event.
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 why the Setup
step above is now a LOT simpler
heroku builds:cache:purge --app=${{ needs.Setup.outputs.APP_NAME }} --confirm=${{ needs.Setup.outputs.APP_NAME }} | ||
heroku config:set BUILDPACK_RUN="pipenv run cookiecutter . --config-file $config_file --no-input -f" --app=${{ needs.Setup.outputs.APP_NAME }} | ||
heroku builds:cache:purge --app=${{ env.APP_NAME }} --confirm=${{ env.APP_NAME }} | ||
heroku config:set BUILDPACK_RUN="pipenv run cookiecutter . --config-file $config_file --no-input -f" --app=${{ env.APP_NAME }} | ||
fi | ||
env: | ||
HEROKU_API_KEY: ${{ secrets.HEROKU_API_KEY }} |
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 Github Action used to do 2 things:
1 - Tell Heroku if it needs to build a Vue app or a React app
2 - Trigger Cypress and cause it to fail early so...(blah blah complicated logic that doesn't exist anymore)
Now all this action does is detect if the dev has touched more React files or more Vue files, and then tell Heroku to change it's build type if a change is needed.
I still don't love that this runs on EVERY commit. I may try to do something smarter, but thats a future PR.
@@ -66,4 +34,4 @@ jobs: | |||
NPM_CONFIG_PRODUCTION: false | |||
CYPRESS_TEST_USER_EMAIL: "cypress@example.com" | |||
CYPRESS_TEST_USER_PASS: {{ "${{ secrets.CYPRESS_TEST_USER_PASS }}" }} | |||
CYPRESS_baseUrl: {{ "${{ needs.Setup.outputs.BASE_URL }}" }} | |||
CYPRESS_baseUrl: {{ "${{ github.event.deployment_status.environment_url }}" }} |
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.
All the comments I made above for the bootstrappers cypress.yml
are relevant here 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.
buuut....since this file is even simpler now, we don't even need a Setup
step anymore
@@ -3,7 +3,7 @@ | |||
# Deploy {{cookiecutter.project_name}} To heroku | |||
# NOTE: This script is intended to deploy the app for the first time to heroku | |||
# if you run it again make and the app is aleady created on heroku make sure to comment lines 6:29 | |||
APP_NAME={{ cookiecutter.project_slug }}-staging.herokuapp.com | |||
APP_NAME={{ cookiecutter.project_slug|replace('_', '-') }}-staging.herokuapp.com | |||
heroku login --interactive | |||
heroku create $APP_NAME --buildpack heroku/python | |||
heroku addons:create heroku-postgresql:mini --app $APP_NAME |
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.
Heroku requires that our URLs use -
instead of _
. Our slugs are the opposite (to be Pythonic).
Annoying and an issue you run into if you bootstrap a project from scratch that has a space in it's name.
The fix isn't always obvious. But I think this is now a solved problem.
@@ -420,7 +420,7 @@ | |||
# Popular testing framework that allows logging to stdout while running unit tests | |||
TEST_RUNNER = "django_nose.NoseTestSuiteRunner" | |||
|
|||
CORS_ALLOWED_ORIGINS = ["https://{{ cookiecutter.project_slug }}-staging.herokuapp.com", "https://{{ cookiecutter.project_slug }}.herokuapp.com"] | |||
CORS_ALLOWED_ORIGINS = ["https://{{ cookiecutter.project_slug|replace('_', '-') }}-staging.herokuapp.com", "https://{{ cookiecutter.project_slug|replace('_', '-') }}.herokuapp.com"] |
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.
same as above. Heroku requires -
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.
Shouldnt be an issue when we remove heroku default in the BS
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.
Correct, hopefully we can find a way to have separate heroku scripts set values like these for the project based on what was actually created in heroku. Obviously this code is effectively guessing what the URL will be (in a deterministic, but fragile way)
@@ -14,6 +14,6 @@ web: gunicorn {{ cookiecutter.project_slug }}.wsgi --chdir=server --log-file - | |||
# 3. Up-to-date build numbers shown in app (ideally auto-generated at build-and-deploy time) | |||
# | |||
# Comment the line below to disable migrations automatically after a Heroku push. | |||
release: python server/manage.py makemigrations --noinput && python server/manage.py migrate --noinput && ./scripts/release.sh | |||
release: python server/manage.py makemigrations --noinput && python server/manage.py migrate --noinput | |||
|
|||
|
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 about test data? should that not get triggered?
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.
Test data gets run once during review app creation. That happens in a different place than this
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.
python3 server/manage.py create_test_data |
db_setup
is what triggers test data to be created.
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.
which is called from the postdeploy
Heroku step.
"postdeploy": "./scripts/db_setup.sh" |
That step only ever gets triggered during review app creation and thus never runs on staging or prod.
Which is why for brand new projects you have to run some of these commands manually once against staging.
@@ -420,7 +420,7 @@ | |||
# Popular testing framework that allows logging to stdout while running unit tests | |||
TEST_RUNNER = "django_nose.NoseTestSuiteRunner" | |||
|
|||
CORS_ALLOWED_ORIGINS = ["https://{{ cookiecutter.project_slug }}-staging.herokuapp.com", "https://{{ cookiecutter.project_slug }}.herokuapp.com"] | |||
CORS_ALLOWED_ORIGINS = ["https://{{ cookiecutter.project_slug|replace('_', '-') }}-staging.herokuapp.com", "https://{{ cookiecutter.project_slug|replace('_', '-') }}.herokuapp.com"] |
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.
Shouldnt be an issue when we remove heroku default in the BS
d4a9ec6
to
a420569
Compare
What this does
The current Cypress setup is too complicated. This change results in the same behavior with much less code and configuration.
Checklist
HEROKU_API_KEY
andGITHUB_TOKEN
from Github and Heroku respectivelyDeploy Notes
n/a
How to test
You will either need to bootstrap a new project or test this on an existing project (PR author has done the later)
Push a commit and observe that the required Chrome and Firefox steps are yellow.
After the release phase in Heroku, observe that Chrome and Firefox are triggered to run.
Push 2 more commits (spaced ~1min apart)
Observe that when the first release phase finishes, Chrome and Firefox are only triggered on the older of the two commits and that the PR is still blocked for merging.
Observe that when the 2nd release phase finishes, Cypress is finally triggered on the newest commit.
Edge cases
Found only one minor edge case. If you push two commits back-to-back quickly, it's possible that when Cypress runs on the first commit that it will be testing the newer version of code. I think this is a very unlikely scenario to occur and, if it does occur, is unlikely to be noticed or matter to the dev team.