| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
Further improves image caching for Breeze (#22625) In order to allow "big" rebuilds we remove the image tag before rebuilding, to make sure that the remote and not local image is used as source of cache. This is consequence of using inlined cache. Files are added to the Python Base image image - the base layers will be shared with other stages but we will make sure that the script stages are different for different platforms. Also - when there is no image at all we fail pre-commit. This should handle the situation when we tried to build the image and stopped it in-between. Hadolint released a new version of their checker - with support for the new Dockerfile buildkit features and native support for ARM so we are enabling it back. See https://github.com/hadolint/hadolint/pull/803 Finally we still need some files that we cannot inline, because they are only needed for source build and they are too long to inline (yarn.lock for example). In order to keep the cache working for all umasks we need to bring back group fixing. | 4 年前 | |
| 3 年前 | ||
Upgrade pip to version 23.0.1 (#29767) | 3 年前 | |
Use MariaDB client binaries in arm64 image for support MySQL backend (#29519) | 3 年前 | |
Fix failing exec in Breeze (#22623) | 4 年前 | |
Upgrade pip to latest released 22.1.0 version (#23665) We are finally able to get rid of the annoying false-positive warnings and we have finally a chance on having warning-free installation during docker builds. | 4 年前 | |
Allow to specify pip version via github URL in Docker/CI workflow (#28697) We've only supported to install pip from released packages with a version number, but since pip does not support RC candidates (as extensively discussed in https://github.com/pypa/pip/issues/10882) we cannot use the release versions to do that. We still want to help pip maintainers and be able to test the versions they release as early as possible, so we add support to install pip in our toolchain from a GitHub URL. That will allow us to test new pip version as soon as designated branch of pip will contain something resembling a release candidate ready for testing. | 3 年前 | |
Allow to specify pip version via github URL in Docker/CI workflow (#28697) We've only supported to install pip from released packages with a version number, but since pip does not support RC candidates (as extensively discussed in https://github.com/pypa/pip/issues/10882) we cannot use the release versions to do that. We still want to help pip maintainers and be able to test the versions they release as early as possible, so we add support to install pip in our toolchain from a GitHub URL. That will allow us to test new pip version as soon as designated branch of pip will contain something resembling a release candidate ready for testing. | 3 年前 | |
Allow to specify pip version via github URL in Docker/CI workflow (#28697) We've only supported to install pip from released packages with a version number, but since pip does not support RC candidates (as extensively discussed in https://github.com/pypa/pip/issues/10882) we cannot use the release versions to do that. We still want to help pip maintainers and be able to test the versions they release as early as possible, so we add support to install pip in our toolchain from a GitHub URL. That will allow us to test new pip version as soon as designated branch of pip will contain something resembling a release candidate ready for testing. | 3 年前 | |
Allow to specify pip version via github URL in Docker/CI workflow (#28697) We've only supported to install pip from released packages with a version number, but since pip does not support RC candidates (as extensively discussed in https://github.com/pypa/pip/issues/10882) we cannot use the release versions to do that. We still want to help pip maintainers and be able to test the versions they release as early as possible, so we add support to install pip in our toolchain from a GitHub URL. That will allow us to test new pip version as soon as designated branch of pip will contain something resembling a release candidate ready for testing. | 3 年前 | |
Add MSSQL support for ARM Docker images (#28533) The #28530 re-enabled support for pymssql installation on ARM. Even if we have no binary wheels, pymssql seems to build cleanly. This is a follow up, to enable mssql client installation for ARM for our images. It also adds docuemntation in Docker image docs to explain it. | 3 年前 | |
Use MariaDB client binaries in arm64 image for support MySQL backend (#29519) | 3 年前 | |
Re-enable Plyvel on ARM as it now builds cleanly (#28443) Previously, Plyvel had to be disabled in order to get ARM compatibility (it did not have binary wheels released and it failed to compile cleanly on debian). But the last problem is fixed now, so we can re-enable it for ARM. | 3 年前 | |
Allow to specify pip version via github URL in Docker/CI workflow (#28697) We've only supported to install pip from released packages with a version number, but since pip does not support RC candidates (as extensively discussed in https://github.com/pypa/pip/issues/10882) we cannot use the release versions to do that. We still want to help pip maintainers and be able to test the versions they release as early as possible, so we add support to install pip in our toolchain from a GitHub URL. That will allow us to test new pip version as soon as designated branch of pip will contain something resembling a release candidate ready for testing. | 3 年前 | |
Upgrade pip to latest released 22.1.0 version (#23665) We are finally able to get rid of the annoying false-positive warnings and we have finally a chance on having warning-free installation during docker builds. | 4 年前 | |
Upgrade Postgres client in Docker images (#21631) | 4 年前 | |
Converts Dockerfiles to be standalone (#22492) This change is one of the biggest optimizations to the Dockerfiles that from the very beginning was a goal, but it has been enabled by switching to buildkit and recent relase of support for the 1.4 dockerfile syntax. This syntax introduced two features: * heredocs * links for COPY commands Both changes allows to solve multiple problems: * COPY for build scripts suffer from permission problems. Depending on umask setting of the host, the scripts could have different group permissions and invalidate docker cache. Inlining the scripts (automatically by pre-commit) gets rid of the problem completely * COPY --link allows to optimize and parallelize builds for Dockerfile.ci embedded source code. This should speed up not only building the images locally but also it will allow to use more efficiently cache for the CI builds (in case no source code change, the builds will use pre-cached layers from the cache more efficiently (and in parallel) * The PROD Dockerfile is now completely standalone. You do not need to have any folders or files to build Airlfow image. At the same time the versatility and support for multiple ways on how you can build the image (as described in https://airflow.apache.org/docs/docker-stack/build.html is maintained (this was a goal from the very beginning of the PROD Dockerfile but it was not easily achievable - heredocs allow to inline scripts that are used for the build and the pre-commits will make sure that there is one source of truth and nicely editable scripts for both PROD and CI Dockerfile. The last point is really cool, because it allows our users to build custom dockerfiles without checking out the code of Airflow, it is enough to download the latest released Dockerfile and they can easily build the image. Overall - this change will vastly optimize build speed for both PROD and CI images in multiple scenarios. | 4 年前 |
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
| 4 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 |