You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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:
Dockerfile
for the application (we don't want to addENTRYPOINT
in it for now, since we suppose that it is better to have container entrypoints inside thedocker-compose
file)docker-compose
fileCompose 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 runmypy
)forum123-flake8
(to runflake8
)forum123-pylint
(to runpylint
)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).
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 intoenvs/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 runmypy
twice - first time, to populatemypy
'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 newmypy
run will not havemypy
's cache from the previous run. Therefore we had to runmypy
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#10600Worth 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.
The text was updated successfully, but these errors were encountered: