PEP-8 enforcements in the project are more of an annoyance than
anything. It doesn't really seem to add much value, and adds a lot of
friction to pull requests from developers who aren't familiar with the
style guide. Stylistic enforcements should just be done during PRs if
necessary (or a different style guide should be enforced).
Tagged builds seem to erroneously fail the on-success check due to the
tests not having finished when the build begins. Since tagged builds are
only ever submitted once the tagged commit is confirmed to pass all
tests, this check will now be skipped.
Introduces a new 'scan' workflow for scanning the main branch container for
vulnerabilities nightly. By default, this will fail for any 'medium' or higher
vulnerability.
Fixes#613
Also adds the ability to overwrite the image in docker-compose.yml,
which allows the CI build to use the same image for all docker tests.
The default is still 'benbusby/whoogle-search' though.
Initializing the DDG bangs when running whoogle for the first time
creates an indeterminate amount of delay before the app becomes usable,
which makes usability tests (particularly w/ Docker) unreliable. This
moves the bang json init to a background thread and writes a temporary
empty dict to the bangs json file until the full bangs json can be used.
Split previous docker test CI into one for PRs and one for triggering
the main buildx workflow that deploys new images to Docker Hub.
Note that this needs to be further refactored soon to use reusable
workflows. The main portion of docker/docker-compose tests is duplicated
between the new main + test workflows.
It makes more sense to structure the order of tests to go from api and
unit testing -> validate docker image works as expected -> build and
deploy docker image.
This expands on the current testing suite a bit by introducing a new
workflow for testing functionality within the docker container. It runs
the same test suite as the regular "test" workflow, but also performs a
health check after running the app for 10 seconds to ensure
functionality.
The buildx workflow now waits for the docker test script to finish
successfully, rather than the regular test workflow. This will hopefully
avoid situations where new images are pushed with issues that aren't
detected in regular testing of the app.
Buildx workflow now waits for tests to pass before building/uploading
new images.
There's also a separate step for building a properly formatted tag image
if triggered by a new tag.
There doesn't really need to be a 'develop' branch anymore, since all
work is committed directly to 'main', with tags to indicate
production-ready builds.
As a result, the buildx-dev workflow is pretty pointless.
Regular commits are all built and publish to TestPyPI, tagged commits
are published to PyPI.
This should finish the process of moving away from Travis CI, now that
both testing and PyPI deployments are handled in github actions.
The Travis CI folks are updating stuff and broke my tests, so I'm moving
over to github actions instead since that is (hopefully) less likely to
change moving forward.
Will need to move PyPi deployment to github actions as well.
Since Docker Hub no longer allows automated builds for free tier users,
the build process for new images needs to be moved to GitHub Actions.
The existing buildx workflow has worked pretty well for the most part,
but was only enabled for the develop branch and only pushed the
buildx-experimental tag. This addition allows pushes to the main branch
to build updates for the "latest" tag as well, which is more commonly
used I think.
Also added debug to list architectures for buildx. Needless to say,
the buildx action is super flakey (as evidenced by a change to the
README breaking the entire build somehow).
The feature request template should not be used for requesting updates to the UI.
There's already a pinned issue for UI customization, and all requests should go there.
Heroku app instances have been notoriously bad at having the instance
automatically upgraded to https. This adds a step in the before request
decorator to always upgrade heroku apps, since they're always deployed
with the certificate, but never configured to upgrade automatically.
Fixes#153
Removed the section concerning which parts of the project would need modification, since it's not always fair to expect someone to know that beforehand.
