mirror of
https://github.com/vee1e/tflite-micro.git
synced 2026-09-01 09:51:22 +00:00
f4c2d0870f
Use Bazel's workspace status mechanism, designed for "stamping" builds with
identifying information from the build environment, to dynamically generate the
version label of the Python distribution package. Generate stamps when Bazel
runs via the --workspace_status_command option and command script. Then use
these stamps in the version label.
Guidelines for Python version labels are given in [PEP 440][]. TFLM does not
currently tag and publish what PEP 440 calls "final releases". Instead,
distribution packages will periodically be published from the tip of the main
branch, and users will be expected to use the latest version or pin to a
historical version of their choice. To facilitate such use, the build system
needs to generate a unique, ascending version label for each commit on the main
branch.
Guided by [PEP 440][], use developmental version labels of the form
*major[.minor].dev<time>*, for example:
0.dev20090103181505
Use a release segment with a major number of 0 (via the standard Bazel
BUILD_EMBED_LABEL stamp), because TFLM does not currently tag and publish
releases. This leaves room in the version space for making semver-style final
releases in the future. Add a developmental release segment with a date and
time stamp.
Packages should be traceable to the exact source from which they were built.
[PEP 440][] does not allow Git hashes in version labels published to PyPI;
however, the Git hash can be embedded in the package's runtime-visible
attribute `tflite_micro.__version__`, and in the package's description, which
is displayed on PyPI.
[PEP 440]: https://peps.python.org/pep-0440
BUG=part of #1484
42 lines
1.8 KiB
Bash
Executable file
42 lines
1.8 KiB
Bash
Executable file
#!/bin/sh
|
|
|
|
# Copyright 2023 The TensorFlow Authors. All Rights Reserved.
|
|
#
|
|
# Licensed under the Apache License, Version 2.0 (the "License");
|
|
# you may not use this file except in compliance with the License.
|
|
# You may obtain a copy of the License at
|
|
#
|
|
# http://www.apache.org/licenses/LICENSE-2.0
|
|
#
|
|
# Unless required by applicable law or agreed to in writing, software
|
|
# distributed under the License is distributed on an "AS IS" BASIS,
|
|
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
|
|
# See the License for the specific language governing permissions and
|
|
# limitations under the License.
|
|
# ---
|
|
|
|
# Output key-value pairs with which to stamp build outputs. This script is
|
|
# called by the bazel option --workspace_status_command, which is likely to be
|
|
# embedded in .bazelrc. Bazel generates some keys, such as BUILD_EMBED_LABEL,
|
|
# on its own, outside of this script. Search for "Bazel workspace status" for
|
|
# more, including the differences between STABLE_ and volatile keys.
|
|
|
|
|
|
# Unambiguous identification of the source tree
|
|
echo STABLE_GIT_HASH $(git describe --always --long --dirty)
|
|
|
|
# Human-readable timestamp of git HEAD's commit date. Use dates derived from
|
|
# git for stability across multiple invocations of the `bazel` command. Use UTC
|
|
# rather than committer or local timezones for consistency across build
|
|
# environments. Use commit date instead of author date, the default date shown
|
|
# by `git log` and GitHub, because amending, rebasing, merging, etc. can cause
|
|
# the author date of descendent commits to be earlier than those of their
|
|
# ancestors.
|
|
#
|
|
# Comparable commit dates can be produced via:
|
|
# `TZ=UTC0 git log --pretty=fuller --date=local`.
|
|
#
|
|
echo STABLE_GIT_COMMIT_TIME $(TZ=UTC0 git show \
|
|
--no-patch \
|
|
--format=format:%cd \
|
|
--date=format-local:%Y%m%d%H%M%S)
|