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

Add basic CI with linters #12

Closed
Tracked by #13
birthdaysgift opened this issue Jan 6, 2023 · 1 comment · Fixed by #13 or #16
Closed
Tracked by #13

Add basic CI with linters #12

birthdaysgift opened this issue Jan 6, 2023 · 1 comment · Fixed by #13 or #16
Assignees
Milestone

Comments

@birthdaysgift
Copy link
Member

birthdaysgift commented Jan 6, 2023

We want PRs to have an explicit indicator for linter errors in the branch/PR. It will allow us to see the state of the branch without explicitly running linters locally if we don't want it.

In the scope of this task we need to add a basic CI pipeline with linters and status indicator on GitHub.

Steps to do:

  • add Dockerfile for the application (we don't want to add ENTRYPOINT in it for now, since we suppose that it is better to have container entrypoints inside the docker-compose file)
  • add docker-compose file
    Compose file should have following services:
  • forum123-build (will be used only to build application image, it will allow us to use caching of the app build on CI)
  • forum123-mypy (to run mypy)
  • forum123-flake8 (to run flake8)
  • forum123-pylint (to run pylint)
    We want them to be separated on different services to be able to run build in one job, and then run all linters in a parallel way in three different jobs (parallel execution will be implemented sometimes later, now we need only to have different services in compose file).
  • setup CI pipeline using GitHub Actions

Also we want to put this configuration in a separate folder like envs/dev to indicate that this is only for development purposes. And when we will need to add some production infrastructure it will go into envs/prod.
Seems like using different folders is more convenient than having a bunch of Dockerfile's and docker-compose files with suffixes like .dev and .prod.

We decided to put mypy stubs in requirements-dev.txt, because we had a troubles with installing types on CI. In our case we had to run mypy twice - first time, to populate mypy's cache and define what types are missing, and second time to install types and check for errors. The cause of this isssue is that github always run its jobs in a new clean containers, so each new mypy run will not have mypy's cache from the previous run. Therefore we had to run mypy twice for every job to have type stubs installed. More about related problems with missing type stubs on CI from other people you can read here: python/mypy#10600

Worth to mention that now we're not going to make this pipeline optimized by performance. We are planning to add caching of intermediate docker layers later in the scope of another task. For now we just need this pipeline to work and nothing more.

@birthdaysgift birthdaysgift self-assigned this Jan 6, 2023
@birthdaysgift birthdaysgift linked a pull request Jan 6, 2023 that will close this issue
1 task
@birthdaysgift birthdaysgift linked a pull request Jan 10, 2023 that will close this issue
@birthdaysgift birthdaysgift added this to the CI/CD milestone Jan 21, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Done
1 participant