certbot/tools/snap/build_remote.py

198 lines
7.1 KiB
Python
Raw Permalink Normal View History

Build snaps using the remote-build feature (#8153) Snapcraft has a feature name `remote-build`. It allows to compile snaps using the Canonical dedicated build architecture for several architectures. Compared to the QEMU-enabled Docker approach used currently, the remote build has several advantages: * the builds are done on the native architecture, making them basically faster than what can be achieved on QEMU * it avoids to depend on `adferrand/snapcraft` (which could be otherwise be fixed with the merge of https://github.com/snapcore/snapcraft/pull/3144, but this will not happen in the short term) * when everything is good, all snaps build can be run in parallel and then can be orchestrated by one single Azure Pipeline job, since the heavy tasks are done remotely. This PR makes the necessary ajustements to use the remote build feature instead of the QEMU-enabled docker approach. One complex task was to be able to compile the `certbot` snap on `arm64` and `armhf`. Indeed on these architectures the pre-compiled wheel for `cffi` is not available. So it needs to be compiled during the snap build. Sadly, the current version of the python plugin in snapcraft is limited by the fact that `wheels` is not installed in the virtual environment set up to build the python packages, and there is no easy way to change that except by overridding the whole build process. In the long term, I think I will open a PR on `snapcraft` Git repository to provide a consistent solution. But for the short term, I used the possibility to provide arguments to the `venv` module, to add the flag `--system-site-packages`. With it, the virtual environment can use the system site package, where `wheel` is available. The other significant additions are in `tools/snap/build_remote.py` script. If invoking the remote build on a local machine is quite straight-forward, it is another story on the CI because we need build auditability and resiliency during these non-interactive actions. In particular we should avoid as possible inconsistent results on the nightly pipeline and the release pipeline. So this script wraps the `snapcraft` call into a retry logic, and improves its logs in the context of parallel builds. For the minor modifications, it is mainly about ensuring that plugins can be built (some of them also need `cffi` for instance), and simplify the Azure Pipeline since all snaps are retrieved in one go. Please note that the `test-` branches still run only the `amd64` architecture. Indeed I noticed that builds on `arm64` and `armhf` are tending to be very slow to start (up to 40 min) while the `amd64` ones wait at max 10 mins, and usually 30 seconds only when the overall load on Canonical side is low. To work on `certbot/certbot` repository, one secured file needs to be added, because `snapcraft` needs to be authenticated against Launchpad with credentials allowing remote builds. To do so, from a local machine that have this capability, one can extract the existing file at `$HOME/.local/share/snapcraft/provider/launchpad/credentials`, and register it as a secured file in Azure Pipeline with the name `snapcraftRemoteBuildCredentials`. * Define scripts * Setup pipeline to use remote builds * Focus on packaging builds * Set credentials * Setup git * Launch all builds in parallel * Add dev dependencies to build cffi and cryptography * Convert to a python logic * Reorganize the pipeline * Handle the fact that snap builds may be taken from cache * Generate constraints * Exit code * Check existence * Try to handle better non zero exit code * Add --system-site-packages to get wheel in the venv * Add executable permissions * Troubleshoot * Dynamic display, take the maximum timeout for snap build job * Allow retries if the remote build does not start * Trigger only amd64 builds for test branches * Exit properly * Update snapcraft.yaml * Fix snap run * Set secured file name * Update .azure-pipelines/templates/jobs/packaging-jobs.yml Co-authored-by: Brad Warren <bmw@users.noreply.github.com> * Update .azure-pipelines/templates/jobs/packaging-jobs.yml Co-authored-by: Brad Warren <bmw@users.noreply.github.com> * Update .azure-pipelines/templates/jobs/packaging-jobs.yml Co-authored-by: Brad Warren <bmw@users.noreply.github.com> * Move order in deps * Reactivate all builds * Use Manager() as a context manager * Use Pool as a context manager * Some nice refactorings * Check snapcraft execution interruption with exit codes * Use f-string and format expressions * Start log * Consistent use of single/double quotes * Better loop to extract lines * Retry on build failures * Few optimizations Co-authored-by: Brad Warren <bmw@users.noreply.github.com>
2020-07-22 19:05:20 -04:00
#!/usr/bin/env python3
import argparse
import glob
import datetime
from multiprocessing import Pool, Process, Manager, Event
import re
import subprocess
import sys
import tempfile
from os.path import join, realpath, dirname, basename, exists
Build snaps using the remote-build feature (#8153) Snapcraft has a feature name `remote-build`. It allows to compile snaps using the Canonical dedicated build architecture for several architectures. Compared to the QEMU-enabled Docker approach used currently, the remote build has several advantages: * the builds are done on the native architecture, making them basically faster than what can be achieved on QEMU * it avoids to depend on `adferrand/snapcraft` (which could be otherwise be fixed with the merge of https://github.com/snapcore/snapcraft/pull/3144, but this will not happen in the short term) * when everything is good, all snaps build can be run in parallel and then can be orchestrated by one single Azure Pipeline job, since the heavy tasks are done remotely. This PR makes the necessary ajustements to use the remote build feature instead of the QEMU-enabled docker approach. One complex task was to be able to compile the `certbot` snap on `arm64` and `armhf`. Indeed on these architectures the pre-compiled wheel for `cffi` is not available. So it needs to be compiled during the snap build. Sadly, the current version of the python plugin in snapcraft is limited by the fact that `wheels` is not installed in the virtual environment set up to build the python packages, and there is no easy way to change that except by overridding the whole build process. In the long term, I think I will open a PR on `snapcraft` Git repository to provide a consistent solution. But for the short term, I used the possibility to provide arguments to the `venv` module, to add the flag `--system-site-packages`. With it, the virtual environment can use the system site package, where `wheel` is available. The other significant additions are in `tools/snap/build_remote.py` script. If invoking the remote build on a local machine is quite straight-forward, it is another story on the CI because we need build auditability and resiliency during these non-interactive actions. In particular we should avoid as possible inconsistent results on the nightly pipeline and the release pipeline. So this script wraps the `snapcraft` call into a retry logic, and improves its logs in the context of parallel builds. For the minor modifications, it is mainly about ensuring that plugins can be built (some of them also need `cffi` for instance), and simplify the Azure Pipeline since all snaps are retrieved in one go. Please note that the `test-` branches still run only the `amd64` architecture. Indeed I noticed that builds on `arm64` and `armhf` are tending to be very slow to start (up to 40 min) while the `amd64` ones wait at max 10 mins, and usually 30 seconds only when the overall load on Canonical side is low. To work on `certbot/certbot` repository, one secured file needs to be added, because `snapcraft` needs to be authenticated against Launchpad with credentials allowing remote builds. To do so, from a local machine that have this capability, one can extract the existing file at `$HOME/.local/share/snapcraft/provider/launchpad/credentials`, and register it as a secured file in Azure Pipeline with the name `snapcraftRemoteBuildCredentials`. * Define scripts * Setup pipeline to use remote builds * Focus on packaging builds * Set credentials * Setup git * Launch all builds in parallel * Add dev dependencies to build cffi and cryptography * Convert to a python logic * Reorganize the pipeline * Handle the fact that snap builds may be taken from cache * Generate constraints * Exit code * Check existence * Try to handle better non zero exit code * Add --system-site-packages to get wheel in the venv * Add executable permissions * Troubleshoot * Dynamic display, take the maximum timeout for snap build job * Allow retries if the remote build does not start * Trigger only amd64 builds for test branches * Exit properly * Update snapcraft.yaml * Fix snap run * Set secured file name * Update .azure-pipelines/templates/jobs/packaging-jobs.yml Co-authored-by: Brad Warren <bmw@users.noreply.github.com> * Update .azure-pipelines/templates/jobs/packaging-jobs.yml Co-authored-by: Brad Warren <bmw@users.noreply.github.com> * Update .azure-pipelines/templates/jobs/packaging-jobs.yml Co-authored-by: Brad Warren <bmw@users.noreply.github.com> * Move order in deps * Reactivate all builds * Use Manager() as a context manager * Use Pool as a context manager * Some nice refactorings * Check snapcraft execution interruption with exit codes * Use f-string and format expressions * Start log * Consistent use of single/double quotes * Better loop to extract lines * Retry on build failures * Few optimizations Co-authored-by: Brad Warren <bmw@users.noreply.github.com>
2020-07-22 19:05:20 -04:00
CERTBOT_DIR = dirname(dirname(dirname(realpath(__file__))))
PLUGINS = [basename(path) for path in glob.glob(join(CERTBOT_DIR, 'certbot-dns-*'))]
def _execute_build(target, archs, status, workspace):
process = subprocess.Popen([
'snapcraft', 'remote-build', '--launchpad-accept-public-upload', '--recover', '--build-on', ','.join(archs)
], stdout=subprocess.PIPE, stderr=subprocess.STDOUT, universal_newlines=True, cwd=workspace)
Build snaps using the remote-build feature (#8153) Snapcraft has a feature name `remote-build`. It allows to compile snaps using the Canonical dedicated build architecture for several architectures. Compared to the QEMU-enabled Docker approach used currently, the remote build has several advantages: * the builds are done on the native architecture, making them basically faster than what can be achieved on QEMU * it avoids to depend on `adferrand/snapcraft` (which could be otherwise be fixed with the merge of https://github.com/snapcore/snapcraft/pull/3144, but this will not happen in the short term) * when everything is good, all snaps build can be run in parallel and then can be orchestrated by one single Azure Pipeline job, since the heavy tasks are done remotely. This PR makes the necessary ajustements to use the remote build feature instead of the QEMU-enabled docker approach. One complex task was to be able to compile the `certbot` snap on `arm64` and `armhf`. Indeed on these architectures the pre-compiled wheel for `cffi` is not available. So it needs to be compiled during the snap build. Sadly, the current version of the python plugin in snapcraft is limited by the fact that `wheels` is not installed in the virtual environment set up to build the python packages, and there is no easy way to change that except by overridding the whole build process. In the long term, I think I will open a PR on `snapcraft` Git repository to provide a consistent solution. But for the short term, I used the possibility to provide arguments to the `venv` module, to add the flag `--system-site-packages`. With it, the virtual environment can use the system site package, where `wheel` is available. The other significant additions are in `tools/snap/build_remote.py` script. If invoking the remote build on a local machine is quite straight-forward, it is another story on the CI because we need build auditability and resiliency during these non-interactive actions. In particular we should avoid as possible inconsistent results on the nightly pipeline and the release pipeline. So this script wraps the `snapcraft` call into a retry logic, and improves its logs in the context of parallel builds. For the minor modifications, it is mainly about ensuring that plugins can be built (some of them also need `cffi` for instance), and simplify the Azure Pipeline since all snaps are retrieved in one go. Please note that the `test-` branches still run only the `amd64` architecture. Indeed I noticed that builds on `arm64` and `armhf` are tending to be very slow to start (up to 40 min) while the `amd64` ones wait at max 10 mins, and usually 30 seconds only when the overall load on Canonical side is low. To work on `certbot/certbot` repository, one secured file needs to be added, because `snapcraft` needs to be authenticated against Launchpad with credentials allowing remote builds. To do so, from a local machine that have this capability, one can extract the existing file at `$HOME/.local/share/snapcraft/provider/launchpad/credentials`, and register it as a secured file in Azure Pipeline with the name `snapcraftRemoteBuildCredentials`. * Define scripts * Setup pipeline to use remote builds * Focus on packaging builds * Set credentials * Setup git * Launch all builds in parallel * Add dev dependencies to build cffi and cryptography * Convert to a python logic * Reorganize the pipeline * Handle the fact that snap builds may be taken from cache * Generate constraints * Exit code * Check existence * Try to handle better non zero exit code * Add --system-site-packages to get wheel in the venv * Add executable permissions * Troubleshoot * Dynamic display, take the maximum timeout for snap build job * Allow retries if the remote build does not start * Trigger only amd64 builds for test branches * Exit properly * Update snapcraft.yaml * Fix snap run * Set secured file name * Update .azure-pipelines/templates/jobs/packaging-jobs.yml Co-authored-by: Brad Warren <bmw@users.noreply.github.com> * Update .azure-pipelines/templates/jobs/packaging-jobs.yml Co-authored-by: Brad Warren <bmw@users.noreply.github.com> * Update .azure-pipelines/templates/jobs/packaging-jobs.yml Co-authored-by: Brad Warren <bmw@users.noreply.github.com> * Move order in deps * Reactivate all builds * Use Manager() as a context manager * Use Pool as a context manager * Some nice refactorings * Check snapcraft execution interruption with exit codes * Use f-string and format expressions * Start log * Consistent use of single/double quotes * Better loop to extract lines * Retry on build failures * Few optimizations Co-authored-by: Brad Warren <bmw@users.noreply.github.com>
2020-07-22 19:05:20 -04:00
process_output = []
Build snaps using the remote-build feature (#8153) Snapcraft has a feature name `remote-build`. It allows to compile snaps using the Canonical dedicated build architecture for several architectures. Compared to the QEMU-enabled Docker approach used currently, the remote build has several advantages: * the builds are done on the native architecture, making them basically faster than what can be achieved on QEMU * it avoids to depend on `adferrand/snapcraft` (which could be otherwise be fixed with the merge of https://github.com/snapcore/snapcraft/pull/3144, but this will not happen in the short term) * when everything is good, all snaps build can be run in parallel and then can be orchestrated by one single Azure Pipeline job, since the heavy tasks are done remotely. This PR makes the necessary ajustements to use the remote build feature instead of the QEMU-enabled docker approach. One complex task was to be able to compile the `certbot` snap on `arm64` and `armhf`. Indeed on these architectures the pre-compiled wheel for `cffi` is not available. So it needs to be compiled during the snap build. Sadly, the current version of the python plugin in snapcraft is limited by the fact that `wheels` is not installed in the virtual environment set up to build the python packages, and there is no easy way to change that except by overridding the whole build process. In the long term, I think I will open a PR on `snapcraft` Git repository to provide a consistent solution. But for the short term, I used the possibility to provide arguments to the `venv` module, to add the flag `--system-site-packages`. With it, the virtual environment can use the system site package, where `wheel` is available. The other significant additions are in `tools/snap/build_remote.py` script. If invoking the remote build on a local machine is quite straight-forward, it is another story on the CI because we need build auditability and resiliency during these non-interactive actions. In particular we should avoid as possible inconsistent results on the nightly pipeline and the release pipeline. So this script wraps the `snapcraft` call into a retry logic, and improves its logs in the context of parallel builds. For the minor modifications, it is mainly about ensuring that plugins can be built (some of them also need `cffi` for instance), and simplify the Azure Pipeline since all snaps are retrieved in one go. Please note that the `test-` branches still run only the `amd64` architecture. Indeed I noticed that builds on `arm64` and `armhf` are tending to be very slow to start (up to 40 min) while the `amd64` ones wait at max 10 mins, and usually 30 seconds only when the overall load on Canonical side is low. To work on `certbot/certbot` repository, one secured file needs to be added, because `snapcraft` needs to be authenticated against Launchpad with credentials allowing remote builds. To do so, from a local machine that have this capability, one can extract the existing file at `$HOME/.local/share/snapcraft/provider/launchpad/credentials`, and register it as a secured file in Azure Pipeline with the name `snapcraftRemoteBuildCredentials`. * Define scripts * Setup pipeline to use remote builds * Focus on packaging builds * Set credentials * Setup git * Launch all builds in parallel * Add dev dependencies to build cffi and cryptography * Convert to a python logic * Reorganize the pipeline * Handle the fact that snap builds may be taken from cache * Generate constraints * Exit code * Check existence * Try to handle better non zero exit code * Add --system-site-packages to get wheel in the venv * Add executable permissions * Troubleshoot * Dynamic display, take the maximum timeout for snap build job * Allow retries if the remote build does not start * Trigger only amd64 builds for test branches * Exit properly * Update snapcraft.yaml * Fix snap run * Set secured file name * Update .azure-pipelines/templates/jobs/packaging-jobs.yml Co-authored-by: Brad Warren <bmw@users.noreply.github.com> * Update .azure-pipelines/templates/jobs/packaging-jobs.yml Co-authored-by: Brad Warren <bmw@users.noreply.github.com> * Update .azure-pipelines/templates/jobs/packaging-jobs.yml Co-authored-by: Brad Warren <bmw@users.noreply.github.com> * Move order in deps * Reactivate all builds * Use Manager() as a context manager * Use Pool as a context manager * Some nice refactorings * Check snapcraft execution interruption with exit codes * Use f-string and format expressions * Start log * Consistent use of single/double quotes * Better loop to extract lines * Retry on build failures * Few optimizations Co-authored-by: Brad Warren <bmw@users.noreply.github.com>
2020-07-22 19:05:20 -04:00
for line in process.stdout:
process_output.append(line)
Build snaps using the remote-build feature (#8153) Snapcraft has a feature name `remote-build`. It allows to compile snaps using the Canonical dedicated build architecture for several architectures. Compared to the QEMU-enabled Docker approach used currently, the remote build has several advantages: * the builds are done on the native architecture, making them basically faster than what can be achieved on QEMU * it avoids to depend on `adferrand/snapcraft` (which could be otherwise be fixed with the merge of https://github.com/snapcore/snapcraft/pull/3144, but this will not happen in the short term) * when everything is good, all snaps build can be run in parallel and then can be orchestrated by one single Azure Pipeline job, since the heavy tasks are done remotely. This PR makes the necessary ajustements to use the remote build feature instead of the QEMU-enabled docker approach. One complex task was to be able to compile the `certbot` snap on `arm64` and `armhf`. Indeed on these architectures the pre-compiled wheel for `cffi` is not available. So it needs to be compiled during the snap build. Sadly, the current version of the python plugin in snapcraft is limited by the fact that `wheels` is not installed in the virtual environment set up to build the python packages, and there is no easy way to change that except by overridding the whole build process. In the long term, I think I will open a PR on `snapcraft` Git repository to provide a consistent solution. But for the short term, I used the possibility to provide arguments to the `venv` module, to add the flag `--system-site-packages`. With it, the virtual environment can use the system site package, where `wheel` is available. The other significant additions are in `tools/snap/build_remote.py` script. If invoking the remote build on a local machine is quite straight-forward, it is another story on the CI because we need build auditability and resiliency during these non-interactive actions. In particular we should avoid as possible inconsistent results on the nightly pipeline and the release pipeline. So this script wraps the `snapcraft` call into a retry logic, and improves its logs in the context of parallel builds. For the minor modifications, it is mainly about ensuring that plugins can be built (some of them also need `cffi` for instance), and simplify the Azure Pipeline since all snaps are retrieved in one go. Please note that the `test-` branches still run only the `amd64` architecture. Indeed I noticed that builds on `arm64` and `armhf` are tending to be very slow to start (up to 40 min) while the `amd64` ones wait at max 10 mins, and usually 30 seconds only when the overall load on Canonical side is low. To work on `certbot/certbot` repository, one secured file needs to be added, because `snapcraft` needs to be authenticated against Launchpad with credentials allowing remote builds. To do so, from a local machine that have this capability, one can extract the existing file at `$HOME/.local/share/snapcraft/provider/launchpad/credentials`, and register it as a secured file in Azure Pipeline with the name `snapcraftRemoteBuildCredentials`. * Define scripts * Setup pipeline to use remote builds * Focus on packaging builds * Set credentials * Setup git * Launch all builds in parallel * Add dev dependencies to build cffi and cryptography * Convert to a python logic * Reorganize the pipeline * Handle the fact that snap builds may be taken from cache * Generate constraints * Exit code * Check existence * Try to handle better non zero exit code * Add --system-site-packages to get wheel in the venv * Add executable permissions * Troubleshoot * Dynamic display, take the maximum timeout for snap build job * Allow retries if the remote build does not start * Trigger only amd64 builds for test branches * Exit properly * Update snapcraft.yaml * Fix snap run * Set secured file name * Update .azure-pipelines/templates/jobs/packaging-jobs.yml Co-authored-by: Brad Warren <bmw@users.noreply.github.com> * Update .azure-pipelines/templates/jobs/packaging-jobs.yml Co-authored-by: Brad Warren <bmw@users.noreply.github.com> * Update .azure-pipelines/templates/jobs/packaging-jobs.yml Co-authored-by: Brad Warren <bmw@users.noreply.github.com> * Move order in deps * Reactivate all builds * Use Manager() as a context manager * Use Pool as a context manager * Some nice refactorings * Check snapcraft execution interruption with exit codes * Use f-string and format expressions * Start log * Consistent use of single/double quotes * Better loop to extract lines * Retry on build failures * Few optimizations Co-authored-by: Brad Warren <bmw@users.noreply.github.com>
2020-07-22 19:05:20 -04:00
_extract_state(target, line, status)
return process.wait(), process_output
Build snaps using the remote-build feature (#8153) Snapcraft has a feature name `remote-build`. It allows to compile snaps using the Canonical dedicated build architecture for several architectures. Compared to the QEMU-enabled Docker approach used currently, the remote build has several advantages: * the builds are done on the native architecture, making them basically faster than what can be achieved on QEMU * it avoids to depend on `adferrand/snapcraft` (which could be otherwise be fixed with the merge of https://github.com/snapcore/snapcraft/pull/3144, but this will not happen in the short term) * when everything is good, all snaps build can be run in parallel and then can be orchestrated by one single Azure Pipeline job, since the heavy tasks are done remotely. This PR makes the necessary ajustements to use the remote build feature instead of the QEMU-enabled docker approach. One complex task was to be able to compile the `certbot` snap on `arm64` and `armhf`. Indeed on these architectures the pre-compiled wheel for `cffi` is not available. So it needs to be compiled during the snap build. Sadly, the current version of the python plugin in snapcraft is limited by the fact that `wheels` is not installed in the virtual environment set up to build the python packages, and there is no easy way to change that except by overridding the whole build process. In the long term, I think I will open a PR on `snapcraft` Git repository to provide a consistent solution. But for the short term, I used the possibility to provide arguments to the `venv` module, to add the flag `--system-site-packages`. With it, the virtual environment can use the system site package, where `wheel` is available. The other significant additions are in `tools/snap/build_remote.py` script. If invoking the remote build on a local machine is quite straight-forward, it is another story on the CI because we need build auditability and resiliency during these non-interactive actions. In particular we should avoid as possible inconsistent results on the nightly pipeline and the release pipeline. So this script wraps the `snapcraft` call into a retry logic, and improves its logs in the context of parallel builds. For the minor modifications, it is mainly about ensuring that plugins can be built (some of them also need `cffi` for instance), and simplify the Azure Pipeline since all snaps are retrieved in one go. Please note that the `test-` branches still run only the `amd64` architecture. Indeed I noticed that builds on `arm64` and `armhf` are tending to be very slow to start (up to 40 min) while the `amd64` ones wait at max 10 mins, and usually 30 seconds only when the overall load on Canonical side is low. To work on `certbot/certbot` repository, one secured file needs to be added, because `snapcraft` needs to be authenticated against Launchpad with credentials allowing remote builds. To do so, from a local machine that have this capability, one can extract the existing file at `$HOME/.local/share/snapcraft/provider/launchpad/credentials`, and register it as a secured file in Azure Pipeline with the name `snapcraftRemoteBuildCredentials`. * Define scripts * Setup pipeline to use remote builds * Focus on packaging builds * Set credentials * Setup git * Launch all builds in parallel * Add dev dependencies to build cffi and cryptography * Convert to a python logic * Reorganize the pipeline * Handle the fact that snap builds may be taken from cache * Generate constraints * Exit code * Check existence * Try to handle better non zero exit code * Add --system-site-packages to get wheel in the venv * Add executable permissions * Troubleshoot * Dynamic display, take the maximum timeout for snap build job * Allow retries if the remote build does not start * Trigger only amd64 builds for test branches * Exit properly * Update snapcraft.yaml * Fix snap run * Set secured file name * Update .azure-pipelines/templates/jobs/packaging-jobs.yml Co-authored-by: Brad Warren <bmw@users.noreply.github.com> * Update .azure-pipelines/templates/jobs/packaging-jobs.yml Co-authored-by: Brad Warren <bmw@users.noreply.github.com> * Update .azure-pipelines/templates/jobs/packaging-jobs.yml Co-authored-by: Brad Warren <bmw@users.noreply.github.com> * Move order in deps * Reactivate all builds * Use Manager() as a context manager * Use Pool as a context manager * Some nice refactorings * Check snapcraft execution interruption with exit codes * Use f-string and format expressions * Start log * Consistent use of single/double quotes * Better loop to extract lines * Retry on build failures * Few optimizations Co-authored-by: Brad Warren <bmw@users.noreply.github.com>
2020-07-22 19:05:20 -04:00
def _build_snap(target, archs, status, lock):
Build snaps using the remote-build feature (#8153) Snapcraft has a feature name `remote-build`. It allows to compile snaps using the Canonical dedicated build architecture for several architectures. Compared to the QEMU-enabled Docker approach used currently, the remote build has several advantages: * the builds are done on the native architecture, making them basically faster than what can be achieved on QEMU * it avoids to depend on `adferrand/snapcraft` (which could be otherwise be fixed with the merge of https://github.com/snapcore/snapcraft/pull/3144, but this will not happen in the short term) * when everything is good, all snaps build can be run in parallel and then can be orchestrated by one single Azure Pipeline job, since the heavy tasks are done remotely. This PR makes the necessary ajustements to use the remote build feature instead of the QEMU-enabled docker approach. One complex task was to be able to compile the `certbot` snap on `arm64` and `armhf`. Indeed on these architectures the pre-compiled wheel for `cffi` is not available. So it needs to be compiled during the snap build. Sadly, the current version of the python plugin in snapcraft is limited by the fact that `wheels` is not installed in the virtual environment set up to build the python packages, and there is no easy way to change that except by overridding the whole build process. In the long term, I think I will open a PR on `snapcraft` Git repository to provide a consistent solution. But for the short term, I used the possibility to provide arguments to the `venv` module, to add the flag `--system-site-packages`. With it, the virtual environment can use the system site package, where `wheel` is available. The other significant additions are in `tools/snap/build_remote.py` script. If invoking the remote build on a local machine is quite straight-forward, it is another story on the CI because we need build auditability and resiliency during these non-interactive actions. In particular we should avoid as possible inconsistent results on the nightly pipeline and the release pipeline. So this script wraps the `snapcraft` call into a retry logic, and improves its logs in the context of parallel builds. For the minor modifications, it is mainly about ensuring that plugins can be built (some of them also need `cffi` for instance), and simplify the Azure Pipeline since all snaps are retrieved in one go. Please note that the `test-` branches still run only the `amd64` architecture. Indeed I noticed that builds on `arm64` and `armhf` are tending to be very slow to start (up to 40 min) while the `amd64` ones wait at max 10 mins, and usually 30 seconds only when the overall load on Canonical side is low. To work on `certbot/certbot` repository, one secured file needs to be added, because `snapcraft` needs to be authenticated against Launchpad with credentials allowing remote builds. To do so, from a local machine that have this capability, one can extract the existing file at `$HOME/.local/share/snapcraft/provider/launchpad/credentials`, and register it as a secured file in Azure Pipeline with the name `snapcraftRemoteBuildCredentials`. * Define scripts * Setup pipeline to use remote builds * Focus on packaging builds * Set credentials * Setup git * Launch all builds in parallel * Add dev dependencies to build cffi and cryptography * Convert to a python logic * Reorganize the pipeline * Handle the fact that snap builds may be taken from cache * Generate constraints * Exit code * Check existence * Try to handle better non zero exit code * Add --system-site-packages to get wheel in the venv * Add executable permissions * Troubleshoot * Dynamic display, take the maximum timeout for snap build job * Allow retries if the remote build does not start * Trigger only amd64 builds for test branches * Exit properly * Update snapcraft.yaml * Fix snap run * Set secured file name * Update .azure-pipelines/templates/jobs/packaging-jobs.yml Co-authored-by: Brad Warren <bmw@users.noreply.github.com> * Update .azure-pipelines/templates/jobs/packaging-jobs.yml Co-authored-by: Brad Warren <bmw@users.noreply.github.com> * Update .azure-pipelines/templates/jobs/packaging-jobs.yml Co-authored-by: Brad Warren <bmw@users.noreply.github.com> * Move order in deps * Reactivate all builds * Use Manager() as a context manager * Use Pool as a context manager * Some nice refactorings * Check snapcraft execution interruption with exit codes * Use f-string and format expressions * Start log * Consistent use of single/double quotes * Better loop to extract lines * Retry on build failures * Few optimizations Co-authored-by: Brad Warren <bmw@users.noreply.github.com>
2020-07-22 19:05:20 -04:00
status[target] = {arch: '...' for arch in archs}
if target == 'certbot':
workspace = CERTBOT_DIR
else:
workspace = join(CERTBOT_DIR, target)
with tempfile.NamedTemporaryFile() as f:
subprocess.check_output(
('"{0}" tools/strip_hashes.py letsencrypt-auto-source/pieces/dependency-requirements.txt '
'| grep -v python-augeas > "{1}"').format(sys.executable, f.name),
shell=True, cwd=CERTBOT_DIR)
subprocess.check_output(
('"{0}" tools/merge_requirements.py tools/dev_constraints.txt '
'"{1}" > "{2}/snap-constraints.txt"').format(sys.executable, f.name, workspace),
Build snaps using the remote-build feature (#8153) Snapcraft has a feature name `remote-build`. It allows to compile snaps using the Canonical dedicated build architecture for several architectures. Compared to the QEMU-enabled Docker approach used currently, the remote build has several advantages: * the builds are done on the native architecture, making them basically faster than what can be achieved on QEMU * it avoids to depend on `adferrand/snapcraft` (which could be otherwise be fixed with the merge of https://github.com/snapcore/snapcraft/pull/3144, but this will not happen in the short term) * when everything is good, all snaps build can be run in parallel and then can be orchestrated by one single Azure Pipeline job, since the heavy tasks are done remotely. This PR makes the necessary ajustements to use the remote build feature instead of the QEMU-enabled docker approach. One complex task was to be able to compile the `certbot` snap on `arm64` and `armhf`. Indeed on these architectures the pre-compiled wheel for `cffi` is not available. So it needs to be compiled during the snap build. Sadly, the current version of the python plugin in snapcraft is limited by the fact that `wheels` is not installed in the virtual environment set up to build the python packages, and there is no easy way to change that except by overridding the whole build process. In the long term, I think I will open a PR on `snapcraft` Git repository to provide a consistent solution. But for the short term, I used the possibility to provide arguments to the `venv` module, to add the flag `--system-site-packages`. With it, the virtual environment can use the system site package, where `wheel` is available. The other significant additions are in `tools/snap/build_remote.py` script. If invoking the remote build on a local machine is quite straight-forward, it is another story on the CI because we need build auditability and resiliency during these non-interactive actions. In particular we should avoid as possible inconsistent results on the nightly pipeline and the release pipeline. So this script wraps the `snapcraft` call into a retry logic, and improves its logs in the context of parallel builds. For the minor modifications, it is mainly about ensuring that plugins can be built (some of them also need `cffi` for instance), and simplify the Azure Pipeline since all snaps are retrieved in one go. Please note that the `test-` branches still run only the `amd64` architecture. Indeed I noticed that builds on `arm64` and `armhf` are tending to be very slow to start (up to 40 min) while the `amd64` ones wait at max 10 mins, and usually 30 seconds only when the overall load on Canonical side is low. To work on `certbot/certbot` repository, one secured file needs to be added, because `snapcraft` needs to be authenticated against Launchpad with credentials allowing remote builds. To do so, from a local machine that have this capability, one can extract the existing file at `$HOME/.local/share/snapcraft/provider/launchpad/credentials`, and register it as a secured file in Azure Pipeline with the name `snapcraftRemoteBuildCredentials`. * Define scripts * Setup pipeline to use remote builds * Focus on packaging builds * Set credentials * Setup git * Launch all builds in parallel * Add dev dependencies to build cffi and cryptography * Convert to a python logic * Reorganize the pipeline * Handle the fact that snap builds may be taken from cache * Generate constraints * Exit code * Check existence * Try to handle better non zero exit code * Add --system-site-packages to get wheel in the venv * Add executable permissions * Troubleshoot * Dynamic display, take the maximum timeout for snap build job * Allow retries if the remote build does not start * Trigger only amd64 builds for test branches * Exit properly * Update snapcraft.yaml * Fix snap run * Set secured file name * Update .azure-pipelines/templates/jobs/packaging-jobs.yml Co-authored-by: Brad Warren <bmw@users.noreply.github.com> * Update .azure-pipelines/templates/jobs/packaging-jobs.yml Co-authored-by: Brad Warren <bmw@users.noreply.github.com> * Update .azure-pipelines/templates/jobs/packaging-jobs.yml Co-authored-by: Brad Warren <bmw@users.noreply.github.com> * Move order in deps * Reactivate all builds * Use Manager() as a context manager * Use Pool as a context manager * Some nice refactorings * Check snapcraft execution interruption with exit codes * Use f-string and format expressions * Start log * Consistent use of single/double quotes * Better loop to extract lines * Retry on build failures * Few optimizations Co-authored-by: Brad Warren <bmw@users.noreply.github.com>
2020-07-22 19:05:20 -04:00
shell=True, cwd=CERTBOT_DIR)
retry = 3
while retry:
exit_code, process_output = _execute_build(target, archs, status, workspace)
Build snaps using the remote-build feature (#8153) Snapcraft has a feature name `remote-build`. It allows to compile snaps using the Canonical dedicated build architecture for several architectures. Compared to the QEMU-enabled Docker approach used currently, the remote build has several advantages: * the builds are done on the native architecture, making them basically faster than what can be achieved on QEMU * it avoids to depend on `adferrand/snapcraft` (which could be otherwise be fixed with the merge of https://github.com/snapcore/snapcraft/pull/3144, but this will not happen in the short term) * when everything is good, all snaps build can be run in parallel and then can be orchestrated by one single Azure Pipeline job, since the heavy tasks are done remotely. This PR makes the necessary ajustements to use the remote build feature instead of the QEMU-enabled docker approach. One complex task was to be able to compile the `certbot` snap on `arm64` and `armhf`. Indeed on these architectures the pre-compiled wheel for `cffi` is not available. So it needs to be compiled during the snap build. Sadly, the current version of the python plugin in snapcraft is limited by the fact that `wheels` is not installed in the virtual environment set up to build the python packages, and there is no easy way to change that except by overridding the whole build process. In the long term, I think I will open a PR on `snapcraft` Git repository to provide a consistent solution. But for the short term, I used the possibility to provide arguments to the `venv` module, to add the flag `--system-site-packages`. With it, the virtual environment can use the system site package, where `wheel` is available. The other significant additions are in `tools/snap/build_remote.py` script. If invoking the remote build on a local machine is quite straight-forward, it is another story on the CI because we need build auditability and resiliency during these non-interactive actions. In particular we should avoid as possible inconsistent results on the nightly pipeline and the release pipeline. So this script wraps the `snapcraft` call into a retry logic, and improves its logs in the context of parallel builds. For the minor modifications, it is mainly about ensuring that plugins can be built (some of them also need `cffi` for instance), and simplify the Azure Pipeline since all snaps are retrieved in one go. Please note that the `test-` branches still run only the `amd64` architecture. Indeed I noticed that builds on `arm64` and `armhf` are tending to be very slow to start (up to 40 min) while the `amd64` ones wait at max 10 mins, and usually 30 seconds only when the overall load on Canonical side is low. To work on `certbot/certbot` repository, one secured file needs to be added, because `snapcraft` needs to be authenticated against Launchpad with credentials allowing remote builds. To do so, from a local machine that have this capability, one can extract the existing file at `$HOME/.local/share/snapcraft/provider/launchpad/credentials`, and register it as a secured file in Azure Pipeline with the name `snapcraftRemoteBuildCredentials`. * Define scripts * Setup pipeline to use remote builds * Focus on packaging builds * Set credentials * Setup git * Launch all builds in parallel * Add dev dependencies to build cffi and cryptography * Convert to a python logic * Reorganize the pipeline * Handle the fact that snap builds may be taken from cache * Generate constraints * Exit code * Check existence * Try to handle better non zero exit code * Add --system-site-packages to get wheel in the venv * Add executable permissions * Troubleshoot * Dynamic display, take the maximum timeout for snap build job * Allow retries if the remote build does not start * Trigger only amd64 builds for test branches * Exit properly * Update snapcraft.yaml * Fix snap run * Set secured file name * Update .azure-pipelines/templates/jobs/packaging-jobs.yml Co-authored-by: Brad Warren <bmw@users.noreply.github.com> * Update .azure-pipelines/templates/jobs/packaging-jobs.yml Co-authored-by: Brad Warren <bmw@users.noreply.github.com> * Update .azure-pipelines/templates/jobs/packaging-jobs.yml Co-authored-by: Brad Warren <bmw@users.noreply.github.com> * Move order in deps * Reactivate all builds * Use Manager() as a context manager * Use Pool as a context manager * Some nice refactorings * Check snapcraft execution interruption with exit codes * Use f-string and format expressions * Start log * Consistent use of single/double quotes * Better loop to extract lines * Retry on build failures * Few optimizations Co-authored-by: Brad Warren <bmw@users.noreply.github.com>
2020-07-22 19:05:20 -04:00
print(f'Build {target} for {",".join(archs)} (attempt {4-retry}/3) ended with exit code {exit_code}.')
sys.stdout.flush()
with lock:
dump_output = exit_code != 0
failed_archs = [arch for arch in archs if status[target][arch] == 'Failed to build']
if exit_code == 0 and not failed_archs:
# We expect to have all target snaps available, or something bad happened.
snaps_list = glob.glob(join(workspace, '*.snap'))
if not len(snaps_list) == len(archs):
print(f'Some of the expected snaps for a successful build are missing (current list: {snaps_list}).')
dump_output = True
else:
break
if failed_archs:
# We expect each failed build to have a log file, or something bad happened.
for arch in failed_archs:
if not exists(join(workspace, f'{target}_{arch}.txt')):
dump_output = True
print(f'Missing output on a failed build {target} for {arch}.')
if dump_output:
print(f'Dumping snapcraft remote-build output build for {target}:')
print('\n'.join(process_output))
# Retry the remote build if it has been interrupted (non zero status code) or if some builds have failed.
Build snaps using the remote-build feature (#8153) Snapcraft has a feature name `remote-build`. It allows to compile snaps using the Canonical dedicated build architecture for several architectures. Compared to the QEMU-enabled Docker approach used currently, the remote build has several advantages: * the builds are done on the native architecture, making them basically faster than what can be achieved on QEMU * it avoids to depend on `adferrand/snapcraft` (which could be otherwise be fixed with the merge of https://github.com/snapcore/snapcraft/pull/3144, but this will not happen in the short term) * when everything is good, all snaps build can be run in parallel and then can be orchestrated by one single Azure Pipeline job, since the heavy tasks are done remotely. This PR makes the necessary ajustements to use the remote build feature instead of the QEMU-enabled docker approach. One complex task was to be able to compile the `certbot` snap on `arm64` and `armhf`. Indeed on these architectures the pre-compiled wheel for `cffi` is not available. So it needs to be compiled during the snap build. Sadly, the current version of the python plugin in snapcraft is limited by the fact that `wheels` is not installed in the virtual environment set up to build the python packages, and there is no easy way to change that except by overridding the whole build process. In the long term, I think I will open a PR on `snapcraft` Git repository to provide a consistent solution. But for the short term, I used the possibility to provide arguments to the `venv` module, to add the flag `--system-site-packages`. With it, the virtual environment can use the system site package, where `wheel` is available. The other significant additions are in `tools/snap/build_remote.py` script. If invoking the remote build on a local machine is quite straight-forward, it is another story on the CI because we need build auditability and resiliency during these non-interactive actions. In particular we should avoid as possible inconsistent results on the nightly pipeline and the release pipeline. So this script wraps the `snapcraft` call into a retry logic, and improves its logs in the context of parallel builds. For the minor modifications, it is mainly about ensuring that plugins can be built (some of them also need `cffi` for instance), and simplify the Azure Pipeline since all snaps are retrieved in one go. Please note that the `test-` branches still run only the `amd64` architecture. Indeed I noticed that builds on `arm64` and `armhf` are tending to be very slow to start (up to 40 min) while the `amd64` ones wait at max 10 mins, and usually 30 seconds only when the overall load on Canonical side is low. To work on `certbot/certbot` repository, one secured file needs to be added, because `snapcraft` needs to be authenticated against Launchpad with credentials allowing remote builds. To do so, from a local machine that have this capability, one can extract the existing file at `$HOME/.local/share/snapcraft/provider/launchpad/credentials`, and register it as a secured file in Azure Pipeline with the name `snapcraftRemoteBuildCredentials`. * Define scripts * Setup pipeline to use remote builds * Focus on packaging builds * Set credentials * Setup git * Launch all builds in parallel * Add dev dependencies to build cffi and cryptography * Convert to a python logic * Reorganize the pipeline * Handle the fact that snap builds may be taken from cache * Generate constraints * Exit code * Check existence * Try to handle better non zero exit code * Add --system-site-packages to get wheel in the venv * Add executable permissions * Troubleshoot * Dynamic display, take the maximum timeout for snap build job * Allow retries if the remote build does not start * Trigger only amd64 builds for test branches * Exit properly * Update snapcraft.yaml * Fix snap run * Set secured file name * Update .azure-pipelines/templates/jobs/packaging-jobs.yml Co-authored-by: Brad Warren <bmw@users.noreply.github.com> * Update .azure-pipelines/templates/jobs/packaging-jobs.yml Co-authored-by: Brad Warren <bmw@users.noreply.github.com> * Update .azure-pipelines/templates/jobs/packaging-jobs.yml Co-authored-by: Brad Warren <bmw@users.noreply.github.com> * Move order in deps * Reactivate all builds * Use Manager() as a context manager * Use Pool as a context manager * Some nice refactorings * Check snapcraft execution interruption with exit codes * Use f-string and format expressions * Start log * Consistent use of single/double quotes * Better loop to extract lines * Retry on build failures * Few optimizations Co-authored-by: Brad Warren <bmw@users.noreply.github.com>
2020-07-22 19:05:20 -04:00
retry = retry - 1
return {target: workspace}
def _extract_state(project, output, status):
match = re.match(r'^.*arch=(\w+)\s+state=([\w ]+).*$', output)
if match:
arch = match.group(1)
state = status[project]
state[arch] = match.group(2)
# You need to reassign the value of status[project] here (rather than doing
# something like status[project][arch] = match.group(2)) for the state change
# to propagate to other processes. See
# https://docs.python.org/3.8/library/multiprocessing.html#proxy-objects for
# more info.
status[project] = state
def _dump_status_helper(archs, status):
headers = ['project', *archs]
print(''.join(f'| {item:<25}' for item in headers))
print(f'|{"-" * 26}' * len(headers))
for project, states in sorted(status.items()):
print(''.join(f'| {item:<25}' for item in [project, *[states[arch] for arch in archs]]))
print(f'|{"-" * 26}' * len(headers))
print()
sys.stdout.flush()
def _dump_status(archs, status, stop_event):
while not stop_event.wait(10):
print('Remote build status at {0}'.format(datetime.datetime.now()))
_dump_status_helper(archs, status)
def _dump_status_final(archs, status):
print('Results for remote build finished at {0}'.format(datetime.datetime.now()))
_dump_status_helper(archs, status)
def _dump_results(targets, archs, status, workspaces):
failures = False
for target in targets:
for arch in archs:
result = status[target][arch]
if result != 'Successfully built':
failures = True
build_output_path = join(workspaces[target], f'{target}_{arch}.txt')
if not exists(build_output_path):
build_output = f'No output has been dumped by snapcraft remote-build.'
else:
with open(join(workspaces[target], '{0}_{1}.txt'.format(target, arch))) as file_h:
build_output = file_h.read()
Build snaps using the remote-build feature (#8153) Snapcraft has a feature name `remote-build`. It allows to compile snaps using the Canonical dedicated build architecture for several architectures. Compared to the QEMU-enabled Docker approach used currently, the remote build has several advantages: * the builds are done on the native architecture, making them basically faster than what can be achieved on QEMU * it avoids to depend on `adferrand/snapcraft` (which could be otherwise be fixed with the merge of https://github.com/snapcore/snapcraft/pull/3144, but this will not happen in the short term) * when everything is good, all snaps build can be run in parallel and then can be orchestrated by one single Azure Pipeline job, since the heavy tasks are done remotely. This PR makes the necessary ajustements to use the remote build feature instead of the QEMU-enabled docker approach. One complex task was to be able to compile the `certbot` snap on `arm64` and `armhf`. Indeed on these architectures the pre-compiled wheel for `cffi` is not available. So it needs to be compiled during the snap build. Sadly, the current version of the python plugin in snapcraft is limited by the fact that `wheels` is not installed in the virtual environment set up to build the python packages, and there is no easy way to change that except by overridding the whole build process. In the long term, I think I will open a PR on `snapcraft` Git repository to provide a consistent solution. But for the short term, I used the possibility to provide arguments to the `venv` module, to add the flag `--system-site-packages`. With it, the virtual environment can use the system site package, where `wheel` is available. The other significant additions are in `tools/snap/build_remote.py` script. If invoking the remote build on a local machine is quite straight-forward, it is another story on the CI because we need build auditability and resiliency during these non-interactive actions. In particular we should avoid as possible inconsistent results on the nightly pipeline and the release pipeline. So this script wraps the `snapcraft` call into a retry logic, and improves its logs in the context of parallel builds. For the minor modifications, it is mainly about ensuring that plugins can be built (some of them also need `cffi` for instance), and simplify the Azure Pipeline since all snaps are retrieved in one go. Please note that the `test-` branches still run only the `amd64` architecture. Indeed I noticed that builds on `arm64` and `armhf` are tending to be very slow to start (up to 40 min) while the `amd64` ones wait at max 10 mins, and usually 30 seconds only when the overall load on Canonical side is low. To work on `certbot/certbot` repository, one secured file needs to be added, because `snapcraft` needs to be authenticated against Launchpad with credentials allowing remote builds. To do so, from a local machine that have this capability, one can extract the existing file at `$HOME/.local/share/snapcraft/provider/launchpad/credentials`, and register it as a secured file in Azure Pipeline with the name `snapcraftRemoteBuildCredentials`. * Define scripts * Setup pipeline to use remote builds * Focus on packaging builds * Set credentials * Setup git * Launch all builds in parallel * Add dev dependencies to build cffi and cryptography * Convert to a python logic * Reorganize the pipeline * Handle the fact that snap builds may be taken from cache * Generate constraints * Exit code * Check existence * Try to handle better non zero exit code * Add --system-site-packages to get wheel in the venv * Add executable permissions * Troubleshoot * Dynamic display, take the maximum timeout for snap build job * Allow retries if the remote build does not start * Trigger only amd64 builds for test branches * Exit properly * Update snapcraft.yaml * Fix snap run * Set secured file name * Update .azure-pipelines/templates/jobs/packaging-jobs.yml Co-authored-by: Brad Warren <bmw@users.noreply.github.com> * Update .azure-pipelines/templates/jobs/packaging-jobs.yml Co-authored-by: Brad Warren <bmw@users.noreply.github.com> * Update .azure-pipelines/templates/jobs/packaging-jobs.yml Co-authored-by: Brad Warren <bmw@users.noreply.github.com> * Move order in deps * Reactivate all builds * Use Manager() as a context manager * Use Pool as a context manager * Some nice refactorings * Check snapcraft execution interruption with exit codes * Use f-string and format expressions * Start log * Consistent use of single/double quotes * Better loop to extract lines * Retry on build failures * Few optimizations Co-authored-by: Brad Warren <bmw@users.noreply.github.com>
2020-07-22 19:05:20 -04:00
print('Output for failed build target={0} arch={1}'.format(target, arch))
print('-------------------------------------------')
print(build_output)
print('-------------------------------------------')
print()
if not failures:
print('All builds succeeded.')
else:
print('Some builds failed.')
return failures
def main():
parser = argparse.ArgumentParser()
parser.add_argument('targets', nargs='+', choices=['ALL', 'DNS_PLUGINS', 'certbot', *PLUGINS],
help='the list of snaps to build')
2020-08-11 15:52:24 -04:00
parser.add_argument('--archs', nargs='+', choices=['amd64', 'arm64', 'armhf'], default=['amd64'],
Build snaps using the remote-build feature (#8153) Snapcraft has a feature name `remote-build`. It allows to compile snaps using the Canonical dedicated build architecture for several architectures. Compared to the QEMU-enabled Docker approach used currently, the remote build has several advantages: * the builds are done on the native architecture, making them basically faster than what can be achieved on QEMU * it avoids to depend on `adferrand/snapcraft` (which could be otherwise be fixed with the merge of https://github.com/snapcore/snapcraft/pull/3144, but this will not happen in the short term) * when everything is good, all snaps build can be run in parallel and then can be orchestrated by one single Azure Pipeline job, since the heavy tasks are done remotely. This PR makes the necessary ajustements to use the remote build feature instead of the QEMU-enabled docker approach. One complex task was to be able to compile the `certbot` snap on `arm64` and `armhf`. Indeed on these architectures the pre-compiled wheel for `cffi` is not available. So it needs to be compiled during the snap build. Sadly, the current version of the python plugin in snapcraft is limited by the fact that `wheels` is not installed in the virtual environment set up to build the python packages, and there is no easy way to change that except by overridding the whole build process. In the long term, I think I will open a PR on `snapcraft` Git repository to provide a consistent solution. But for the short term, I used the possibility to provide arguments to the `venv` module, to add the flag `--system-site-packages`. With it, the virtual environment can use the system site package, where `wheel` is available. The other significant additions are in `tools/snap/build_remote.py` script. If invoking the remote build on a local machine is quite straight-forward, it is another story on the CI because we need build auditability and resiliency during these non-interactive actions. In particular we should avoid as possible inconsistent results on the nightly pipeline and the release pipeline. So this script wraps the `snapcraft` call into a retry logic, and improves its logs in the context of parallel builds. For the minor modifications, it is mainly about ensuring that plugins can be built (some of them also need `cffi` for instance), and simplify the Azure Pipeline since all snaps are retrieved in one go. Please note that the `test-` branches still run only the `amd64` architecture. Indeed I noticed that builds on `arm64` and `armhf` are tending to be very slow to start (up to 40 min) while the `amd64` ones wait at max 10 mins, and usually 30 seconds only when the overall load on Canonical side is low. To work on `certbot/certbot` repository, one secured file needs to be added, because `snapcraft` needs to be authenticated against Launchpad with credentials allowing remote builds. To do so, from a local machine that have this capability, one can extract the existing file at `$HOME/.local/share/snapcraft/provider/launchpad/credentials`, and register it as a secured file in Azure Pipeline with the name `snapcraftRemoteBuildCredentials`. * Define scripts * Setup pipeline to use remote builds * Focus on packaging builds * Set credentials * Setup git * Launch all builds in parallel * Add dev dependencies to build cffi and cryptography * Convert to a python logic * Reorganize the pipeline * Handle the fact that snap builds may be taken from cache * Generate constraints * Exit code * Check existence * Try to handle better non zero exit code * Add --system-site-packages to get wheel in the venv * Add executable permissions * Troubleshoot * Dynamic display, take the maximum timeout for snap build job * Allow retries if the remote build does not start * Trigger only amd64 builds for test branches * Exit properly * Update snapcraft.yaml * Fix snap run * Set secured file name * Update .azure-pipelines/templates/jobs/packaging-jobs.yml Co-authored-by: Brad Warren <bmw@users.noreply.github.com> * Update .azure-pipelines/templates/jobs/packaging-jobs.yml Co-authored-by: Brad Warren <bmw@users.noreply.github.com> * Update .azure-pipelines/templates/jobs/packaging-jobs.yml Co-authored-by: Brad Warren <bmw@users.noreply.github.com> * Move order in deps * Reactivate all builds * Use Manager() as a context manager * Use Pool as a context manager * Some nice refactorings * Check snapcraft execution interruption with exit codes * Use f-string and format expressions * Start log * Consistent use of single/double quotes * Better loop to extract lines * Retry on build failures * Few optimizations Co-authored-by: Brad Warren <bmw@users.noreply.github.com>
2020-07-22 19:05:20 -04:00
help='the architectures for which snaps are built')
args = parser.parse_args()
archs = set(args.archs)
targets = set(args.targets)
if 'ALL' in targets:
targets.remove('ALL')
targets.update(['certbot', 'DNS_PLUGINS'])
if 'DNS_PLUGINS' in targets:
targets.remove('DNS_PLUGINS')
targets.update(PLUGINS)
print('Start remote snap builds...')
print(f' - archs: {", ".join(archs)}')
print(f' - projects: {", ".join(sorted(targets))}')
print()
with Manager() as manager, Pool(processes=len(targets)) as pool:
status = manager.dict()
lock = manager.Lock()
Build snaps using the remote-build feature (#8153) Snapcraft has a feature name `remote-build`. It allows to compile snaps using the Canonical dedicated build architecture for several architectures. Compared to the QEMU-enabled Docker approach used currently, the remote build has several advantages: * the builds are done on the native architecture, making them basically faster than what can be achieved on QEMU * it avoids to depend on `adferrand/snapcraft` (which could be otherwise be fixed with the merge of https://github.com/snapcore/snapcraft/pull/3144, but this will not happen in the short term) * when everything is good, all snaps build can be run in parallel and then can be orchestrated by one single Azure Pipeline job, since the heavy tasks are done remotely. This PR makes the necessary ajustements to use the remote build feature instead of the QEMU-enabled docker approach. One complex task was to be able to compile the `certbot` snap on `arm64` and `armhf`. Indeed on these architectures the pre-compiled wheel for `cffi` is not available. So it needs to be compiled during the snap build. Sadly, the current version of the python plugin in snapcraft is limited by the fact that `wheels` is not installed in the virtual environment set up to build the python packages, and there is no easy way to change that except by overridding the whole build process. In the long term, I think I will open a PR on `snapcraft` Git repository to provide a consistent solution. But for the short term, I used the possibility to provide arguments to the `venv` module, to add the flag `--system-site-packages`. With it, the virtual environment can use the system site package, where `wheel` is available. The other significant additions are in `tools/snap/build_remote.py` script. If invoking the remote build on a local machine is quite straight-forward, it is another story on the CI because we need build auditability and resiliency during these non-interactive actions. In particular we should avoid as possible inconsistent results on the nightly pipeline and the release pipeline. So this script wraps the `snapcraft` call into a retry logic, and improves its logs in the context of parallel builds. For the minor modifications, it is mainly about ensuring that plugins can be built (some of them also need `cffi` for instance), and simplify the Azure Pipeline since all snaps are retrieved in one go. Please note that the `test-` branches still run only the `amd64` architecture. Indeed I noticed that builds on `arm64` and `armhf` are tending to be very slow to start (up to 40 min) while the `amd64` ones wait at max 10 mins, and usually 30 seconds only when the overall load on Canonical side is low. To work on `certbot/certbot` repository, one secured file needs to be added, because `snapcraft` needs to be authenticated against Launchpad with credentials allowing remote builds. To do so, from a local machine that have this capability, one can extract the existing file at `$HOME/.local/share/snapcraft/provider/launchpad/credentials`, and register it as a secured file in Azure Pipeline with the name `snapcraftRemoteBuildCredentials`. * Define scripts * Setup pipeline to use remote builds * Focus on packaging builds * Set credentials * Setup git * Launch all builds in parallel * Add dev dependencies to build cffi and cryptography * Convert to a python logic * Reorganize the pipeline * Handle the fact that snap builds may be taken from cache * Generate constraints * Exit code * Check existence * Try to handle better non zero exit code * Add --system-site-packages to get wheel in the venv * Add executable permissions * Troubleshoot * Dynamic display, take the maximum timeout for snap build job * Allow retries if the remote build does not start * Trigger only amd64 builds for test branches * Exit properly * Update snapcraft.yaml * Fix snap run * Set secured file name * Update .azure-pipelines/templates/jobs/packaging-jobs.yml Co-authored-by: Brad Warren <bmw@users.noreply.github.com> * Update .azure-pipelines/templates/jobs/packaging-jobs.yml Co-authored-by: Brad Warren <bmw@users.noreply.github.com> * Update .azure-pipelines/templates/jobs/packaging-jobs.yml Co-authored-by: Brad Warren <bmw@users.noreply.github.com> * Move order in deps * Reactivate all builds * Use Manager() as a context manager * Use Pool as a context manager * Some nice refactorings * Check snapcraft execution interruption with exit codes * Use f-string and format expressions * Start log * Consistent use of single/double quotes * Better loop to extract lines * Retry on build failures * Few optimizations Co-authored-by: Brad Warren <bmw@users.noreply.github.com>
2020-07-22 19:05:20 -04:00
stop_event = Event()
state_process = Process(target=_dump_status, args=(archs, status, stop_event))
state_process.start()
async_results = [pool.apply_async(_build_snap, (target, archs, status, lock)) for target in targets]
Build snaps using the remote-build feature (#8153) Snapcraft has a feature name `remote-build`. It allows to compile snaps using the Canonical dedicated build architecture for several architectures. Compared to the QEMU-enabled Docker approach used currently, the remote build has several advantages: * the builds are done on the native architecture, making them basically faster than what can be achieved on QEMU * it avoids to depend on `adferrand/snapcraft` (which could be otherwise be fixed with the merge of https://github.com/snapcore/snapcraft/pull/3144, but this will not happen in the short term) * when everything is good, all snaps build can be run in parallel and then can be orchestrated by one single Azure Pipeline job, since the heavy tasks are done remotely. This PR makes the necessary ajustements to use the remote build feature instead of the QEMU-enabled docker approach. One complex task was to be able to compile the `certbot` snap on `arm64` and `armhf`. Indeed on these architectures the pre-compiled wheel for `cffi` is not available. So it needs to be compiled during the snap build. Sadly, the current version of the python plugin in snapcraft is limited by the fact that `wheels` is not installed in the virtual environment set up to build the python packages, and there is no easy way to change that except by overridding the whole build process. In the long term, I think I will open a PR on `snapcraft` Git repository to provide a consistent solution. But for the short term, I used the possibility to provide arguments to the `venv` module, to add the flag `--system-site-packages`. With it, the virtual environment can use the system site package, where `wheel` is available. The other significant additions are in `tools/snap/build_remote.py` script. If invoking the remote build on a local machine is quite straight-forward, it is another story on the CI because we need build auditability and resiliency during these non-interactive actions. In particular we should avoid as possible inconsistent results on the nightly pipeline and the release pipeline. So this script wraps the `snapcraft` call into a retry logic, and improves its logs in the context of parallel builds. For the minor modifications, it is mainly about ensuring that plugins can be built (some of them also need `cffi` for instance), and simplify the Azure Pipeline since all snaps are retrieved in one go. Please note that the `test-` branches still run only the `amd64` architecture. Indeed I noticed that builds on `arm64` and `armhf` are tending to be very slow to start (up to 40 min) while the `amd64` ones wait at max 10 mins, and usually 30 seconds only when the overall load on Canonical side is low. To work on `certbot/certbot` repository, one secured file needs to be added, because `snapcraft` needs to be authenticated against Launchpad with credentials allowing remote builds. To do so, from a local machine that have this capability, one can extract the existing file at `$HOME/.local/share/snapcraft/provider/launchpad/credentials`, and register it as a secured file in Azure Pipeline with the name `snapcraftRemoteBuildCredentials`. * Define scripts * Setup pipeline to use remote builds * Focus on packaging builds * Set credentials * Setup git * Launch all builds in parallel * Add dev dependencies to build cffi and cryptography * Convert to a python logic * Reorganize the pipeline * Handle the fact that snap builds may be taken from cache * Generate constraints * Exit code * Check existence * Try to handle better non zero exit code * Add --system-site-packages to get wheel in the venv * Add executable permissions * Troubleshoot * Dynamic display, take the maximum timeout for snap build job * Allow retries if the remote build does not start * Trigger only amd64 builds for test branches * Exit properly * Update snapcraft.yaml * Fix snap run * Set secured file name * Update .azure-pipelines/templates/jobs/packaging-jobs.yml Co-authored-by: Brad Warren <bmw@users.noreply.github.com> * Update .azure-pipelines/templates/jobs/packaging-jobs.yml Co-authored-by: Brad Warren <bmw@users.noreply.github.com> * Update .azure-pipelines/templates/jobs/packaging-jobs.yml Co-authored-by: Brad Warren <bmw@users.noreply.github.com> * Move order in deps * Reactivate all builds * Use Manager() as a context manager * Use Pool as a context manager * Some nice refactorings * Check snapcraft execution interruption with exit codes * Use f-string and format expressions * Start log * Consistent use of single/double quotes * Better loop to extract lines * Retry on build failures * Few optimizations Co-authored-by: Brad Warren <bmw@users.noreply.github.com>
2020-07-22 19:05:20 -04:00
workspaces = {}
for async_result in async_results:
workspaces.update(async_result.get())
stop_event.set()
state_process.join()
failures = _dump_results(targets, archs, status, workspaces)
_dump_status_final(archs, status)
return 1 if failures else 0
if __name__ == '__main__':
sys.exit(main())