summaryrefslogtreecommitdiffstats
path: root/bitbake/doc
diff options
context:
space:
mode:
authorEmil Ekmečić <eekmecic@snap.com>2023-08-09 02:39:44 -0700
committerRichard Purdie <richard.purdie@linuxfoundation.org>2023-08-11 16:23:01 +0100
commitac5512b0acf3457a4c459d4d1711649053f4e618 (patch)
treedfa8627a0c3c6e2c0c8092c5cf91475dcaed8839 /bitbake/doc
parent71282bbc5331e7768c95d1dd6db94651de504734 (diff)
downloadpoky-ac5512b0acf3457a4c459d4d1711649053f4e618.tar.gz
bitbake: fetch2: add Google Cloud Platform (GCP) fetcher
This fetcher allows BitBake to fetch from a Google Cloud Storage bucket. The fetcher expects a gs:// URI of the following form: SSTATE_MIRRORS = "file://.* gs://<bucket name>/PATH" The fetcher uses the Google Cloud Storage Python Client, and expects it to be installed, configured, and authenticated prior to use. If accepted, this patch should merge in with the corresponding oe-core patch titled "Add GCP fetcher to list of supported protocols". Some comments on the patch: There is also documentation for the fetcher added to the User Manual. I'm still not completely sure about the recommends_checksum() being set to True. As I've noted in the mailing list, it will throw warnings if the fetcher is used in recipes without specifying a checksum. Please let me know if this is intended behavior or if it should be modified. Here is how this fetcher conforms to the fetcher expectations described at this link: https://git.yoctoproject.org/poky/tree/bitbake/lib/bb/fetch2/README a) Yes, network fetching only happens in the fetcher b) The fetcher has nothing to do with the unpack phase so there is no network access there c) This change doesn't affect the behavior of DL_DIR. The GCP fetcher only downloads to the DL_DIR in the same way that other fetchers, namely the S3 and Azure fetchers do. d) The fetcher is identical to the S3 and Azure fetchers in this context e) Yes, the fetcher output is deterministic because it is downloading tarballs from a bucket and not modifying them in any way. f) I set up a local proxy using tinyproxy and set the http_proxy variable to test whether the Python API respected the proxy. It appears that it did as I could see traffic passing through the proxy. I also did some searching online and found posts indicating that the Google Cloud Python APIs supported the classic Linux proxy variables, namely: - https://github.com/googleapis/google-api-python-client/issues/1260 g) Access is minimal, only checking if the file exists and downloading it if it does. h) Not applicable, BitBake already knows which version it wants and the version infomation is encoded in the filename. The fetcher has no concept of versions. i) Not applicable j) Not applicable k) No tests were added as part of this change. I didn't see any tests for the S3 or Azure changes either, is that OK? l) I'm not 100% familiar but I don't believe this fetcher is using any tools during parse time. Please correct me if I'm wrong. (Bitbake rev: 8e7e5719c1de79eb488732818871add3a6fc238b) Signed-off-by: Emil Ekmečić <eekmecic@snap.com> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Diffstat (limited to 'bitbake/doc')
-rw-r--r--bitbake/doc/bitbake-user-manual/bitbake-user-manual-fetching.rst36
1 files changed, 36 insertions, 0 deletions
diff --git a/bitbake/doc/bitbake-user-manual/bitbake-user-manual-fetching.rst b/bitbake/doc/bitbake-user-manual/bitbake-user-manual-fetching.rst
index c061bd70ea..f5723d6767 100644
--- a/bitbake/doc/bitbake-user-manual/bitbake-user-manual-fetching.rst
+++ b/bitbake/doc/bitbake-user-manual/bitbake-user-manual-fetching.rst
@@ -688,6 +688,40 @@ Here is an example URL::
688 688
689It can also be used when setting mirrors definitions using the :term:`PREMIRRORS` variable. 689It can also be used when setting mirrors definitions using the :term:`PREMIRRORS` variable.
690 690
691.. _gcp-fetcher:
692
693GCP Fetcher (``gs://``)
694--------------------------
695
696This submodule fetches data from a
697`Google Cloud Storage Bucket <https://cloud.google.com/storage/docs/buckets>`__.
698It uses the `Google Cloud Storage Python Client <https://cloud.google.com/python/docs/reference/storage/latest>`__
699to check the status of objects in the bucket and download them.
700The use of the Python client makes it substantially faster than using command
701line tools such as gsutil.
702
703The fetcher requires the Google Cloud Storage Python Client to be installed, along
704with the gsutil tool.
705
706The fetcher requires that the machine has valid credentials for accessing the
707chosen bucket. Instructions for authentication can be found in the
708`Google Cloud documentation <https://cloud.google.com/docs/authentication/provide-credentials-adc#local-dev>`__.
709
710The fetcher can be used for fetching sstate artifacts from a GCS bucket by
711specifying the :term:`SSTATE_MIRRORS` variable as shown below::
712
713 SSTATE_MIRRORS ?= "\
714 file://.* gs://<bucket name>/PATH \
715 "
716
717The fetcher can also be used in recipes::
718
719 SRC_URI = "gs://<bucket name>/<foo_container>/<bar_file>"
720
721However, the checksum of the file should be also be provided::
722
723 SRC_URI[sha256sum] = "<sha256 string>"
724
691.. _crate-fetcher: 725.. _crate-fetcher:
692 726
693Crate Fetcher (``crate://``) 727Crate Fetcher (``crate://``)
@@ -791,6 +825,8 @@ Fetch submodules also exist for the following:
791 825
792- OSC (``osc://``) 826- OSC (``osc://``)
793 827
828- S3 (``s3://``)
829
794- Secure FTP (``sftp://``) 830- Secure FTP (``sftp://``)
795 831
796- Secure Shell (``ssh://``) 832- Secure Shell (``ssh://``)