|
| 1 | +Bob 0.25 Release Notes |
| 2 | +====================== |
| 3 | + |
| 4 | +Changes made since Bob 0.24.0 include the following. |
| 5 | + |
| 6 | +Upcoming 1.0 release |
| 7 | +-------------------- |
| 8 | + |
| 9 | +It is anticipated that the next release will be 1.0. |
| 10 | + |
| 11 | +As announced previously, support for pre-0.16 projects has been removed. If no |
| 12 | +``config.yaml`` is present, version ``0.16`` is implied. Likewise, all policies |
| 13 | +that were introduced before have been :ref:`declared obsolete <policies-obsolete>` |
| 14 | +and may not be set to their old behaviour. (See :pull:`557`) |
| 15 | + |
| 16 | + |
| 17 | +New features |
| 18 | +------------ |
| 19 | + |
| 20 | +SCM backed layers |
| 21 | +~~~~~~~~~~~~~~~~~ |
| 22 | + |
| 23 | +Previously, layers had to be managed outside of Bob. Typically this involved |
| 24 | +git submodules or similar means. Bob now gained the possibility to checkout and |
| 25 | +update them directly. Instead of just referencing the layer name in |
| 26 | +:ref:`config.yaml <configuration-config>`, the SCM source can be specified |
| 27 | +too:: |
| 28 | + |
| 29 | + layers: |
| 30 | + - name: myapp |
| 31 | + scm: git |
| 32 | + |
| 33 | + commit: ... |
| 34 | + - bsp |
| 35 | + |
| 36 | +In the example above, the ``myapp`` layer is cloned via git while the ``bsp`` |
| 37 | +layer is expected to exist. If a layer SCM specification is given, Bob takes |
| 38 | +care of the layer management: |
| 39 | + |
| 40 | +- Layers are checked out / updated during ``bob build/dev`` (except |
| 41 | + build-only). |
| 42 | +- The ``bob layers`` command can update layers or show their status (see |
| 43 | + :ref:`manpage-layers`). |
| 44 | + |
| 45 | +(:pull:`561`, :pull:`587`, :pull:`588`, :pull:`589`, :pull:`593`. See |
| 46 | +:ref:`configuration-config-layers`.) |
| 47 | + |
| 48 | +More flexible sandbox modes |
| 49 | +~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
| 50 | + |
| 51 | +Sandboxing allows to execute the build steps in ephemeral containers. So far, |
| 52 | +the long existing ``--sandbox`` option provides partial isolation only if a |
| 53 | +sandbox image is available for a package. Inside the sandbox image all paths |
| 54 | +are stable, i.e. independent of the workspace path. To provide more |
| 55 | +flexibility, the ``bob build/dev/jenkins`` commands gained three new sandbox |
| 56 | +modes. |
| 57 | + |
| 58 | +As a light-weight alternative, the ``--slim-sandbox`` option has been added to |
| 59 | +provide isolation without using a potentially available sandbox image. All |
| 60 | +workspace paths are retained. Likewise, the added ``--dev-sandbox`` option will |
| 61 | +also provide full isolation but an available sandbox image is used. The |
| 62 | +``--strict-sandbox`` option further uses stable paths consistently. |
| 63 | + |
| 64 | +See :ref:`manpage-build`, resp. :ref:`manpage-dev`. (:pull:`591`) |
| 65 | + |
| 66 | +Recipes |
| 67 | +~~~~~~~ |
| 68 | + |
| 69 | +* The ``git`` :ref:`configuration-recipes-scm` gained the ``rebase`` option. |
| 70 | + |
| 71 | + Sometimes upstream branches are rebased. While this behaviour is frowned |
| 72 | + upon, it is still necessary to cope with such situations. The optional |
| 73 | + ``rebase`` attribute, if set to true, will cause Bob to rebase the local |
| 74 | + branch instead of doing a fast-forward merge. |
| 75 | +* Added the ``inherit`` dependency property to :ref:`configuration-recipes-depends` |
| 76 | + items. |
| 77 | + |
| 78 | + This property controls the inheritance of environment, tools and sandbox for |
| 79 | + a dependency. It defaults to ``true``, so everything is inherited. If set to |
| 80 | + ``false``, environment, tools and sandbox are dropped. The dependency starts |
| 81 | + with the default-environment, no tools and no sandbox. |
| 82 | + |
| 83 | + This becomes particularly useful when an existing root-package should become |
| 84 | + a dependency of another root-package, e.g. for building an installer. |
| 85 | + |
| 86 | + (:pull:`565`) |
| 87 | +* Environment substitution is now applied to :ref:`configuration-recipes-checkoutassert`. |
| 88 | + |
| 89 | + If variables are used to control the checkout of a package, the |
| 90 | + :ref:`configuration-recipes-checkoutassert` might need to be variable as |
| 91 | + well. (:pull:`567`) |
| 92 | +* Bob now applies variable substitution in :ref:`configuration-recipes-metaenv`. |
| 93 | + (:issue:`573`) |
| 94 | +* Tools can be used conditionally. |
| 95 | + |
| 96 | + Sometimes a recipe might only require a tool if certain conditions are met. |
| 97 | + So far, tools could only be used unconditionally. Bob gained a new syntax |
| 98 | + along the following lines:: |
| 99 | + |
| 100 | + checkoutTools: |
| 101 | + - if: "${TEST_VAR:-}" |
| 102 | + name: graphics::package |
| 103 | + |
| 104 | + (:issue:`572`, see :ref:`configuration-recipes-tools`). |
| 105 | + |
| 106 | +User configuration (default.yaml) |
| 107 | +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
| 108 | + |
| 109 | +* Gained an option to set the user identity inside the sandbox. |
| 110 | + |
| 111 | + Apparently, some license check tools require to observe the same user and |
| 112 | + group ID inside the sandbox. An option has been added to the sandbox |
| 113 | + definition and user configuration to override the user inside the sandbox. |
| 114 | + The default is ``nobody`` which reflects the traditional behaviour. The new |
| 115 | + options ``root`` and ``$USER`` set the UID to either 0 (root) or keep the UID |
| 116 | + of the current user. |
| 117 | + |
| 118 | + See :ref:`configuration-config-sandbox`. (:pull:`559`) |
| 119 | +* Added user path expansion for local archive backend. |
| 120 | + |
| 121 | + Bob applies user path expansion to the given path of a "file" archive |
| 122 | + backend. This could be used to place an artifact cache in the user |
| 123 | + directory, e.g. in ``~/.cache/bob/artifacts``:: |
| 124 | + |
| 125 | + archivePrepend: |
| 126 | + - backend: file |
| 127 | + path: "~/.cache/bob/artifacts" |
| 128 | + flags: [download, cache] |
| 129 | + |
| 130 | + (:pull:`574`) |
| 131 | + |
| 132 | +Improvements |
| 133 | +------------ |
| 134 | + |
| 135 | +* Bob has been made compatible to Python 3.12. |
| 136 | +* Added a :ref:`recommended user configuration <installation-recommended-config>` |
| 137 | + to the documentation. |
| 138 | +* The build scheduling has been improved. Now Bob builds ``use: [result]`` |
| 139 | + dependencies and used tools in parallel instead of first all tools and then all |
| 140 | + dependencies. |
| 141 | +* WebDAV compatibility has been improved for binary artifact uploads. |
| 142 | + |
| 143 | + So far, Bob incorrectly assumed that the parent directories are created |
| 144 | + automatically (e.g. on Nginx via "create_full_put_path on"). There is no such |
| 145 | + option on, e.g. Apache. Instead of assuming such non-compliant behavior, Bob |
| 146 | + now always does an ``MKCOL`` request for the parent directory first. |
| 147 | + |
| 148 | + (:pull:`571`) |
| 149 | +* Added a Dockerfile to the contrib folder. It creates a a Debian based |
| 150 | + container with bob. It can be used to build bob projects in a container. |
| 151 | + |
| 152 | +Backwards incompatible changes |
| 153 | +------------------------------ |
| 154 | + |
| 155 | +* Support for Python 3.6 has been dropped. |
| 156 | +* Support for projects targeting Bob versions before ``0.16`` has been removed. |
| 157 | + If no ``config.yaml`` is present, or no :ref:`configuration-bobMinimumVersion` |
| 158 | + is specified, version ``0.16`` is assumed. |
| 159 | +* The ``filter`` recipe keyword has been removed. It was never used in practice. |
| 160 | +* Support for nested layers has been dropped in favour of layer SCM support. |
| 161 | + (:pull:`561`. See :ref:`configuration-config-layers`.) |
| 162 | + |
| 163 | +Bug fixes |
| 164 | +--------- |
| 165 | + |
| 166 | +* Fix build of fingerprinted packages with different sandbox images. |
| 167 | + |
| 168 | + If a package is fingerprinted, the result is effectively declared to |
| 169 | + depend on the host system. How exactly is not known to Bob. Despite the |
| 170 | + actual host system, each sandbox represents a potentially different host |
| 171 | + system environment. This means that the same fingerprint script might |
| 172 | + yield different results if being executed in a sandbox, a different |
| 173 | + sandbox or the host system. |
| 174 | + |
| 175 | + This implies that packages which are fingerprinted need to be built |
| 176 | + separately for the host system and each sandbox image. With the |
| 177 | + introduction of the :ref:`policies-sandboxInvariant`, Bob erroneously coalesced |
| 178 | + fingerprinted packages which only differ in their host/sandbox |
| 179 | + environment. Now Bob will always use separate workspaces again for such |
| 180 | + packages. |
| 181 | + |
| 182 | + The fix will impact the calculation of the :term:`Variant-Id` which might lead |
| 183 | + to some rebuilds. On the other hand, the :term:`Build-Id` is not affected and |
| 184 | + existing binary artifacts will continue to be used. |
| 185 | +* Fixed ``git`` branch check when inline switching nested SCMs. |
| 186 | + |
| 187 | + When switching branches, Bob first checks if the new branch already |
| 188 | + exists in the workspace. Unfortunately, the check did not consider the |
| 189 | + subdirectory of the SCM, so it might have wrongly concluded that the branch |
| 190 | + exists in case of nested repositories. |
| 191 | +* Fixed a typo in the build log messages (:pull:`563`) |
| 192 | +* Bob now does clean builds if the path to a tool changes. |
| 193 | + |
| 194 | + The builds step implicitly depends on the execution path of all dependencies. |
| 195 | + So far, we only tracked arguments. But some build systems also store the |
| 196 | + absolute path to tools. In this case, the build will fail if a tool path |
| 197 | + changes. Now changed tool paths also trigger a clean rebuild. |
| 198 | + |
| 199 | + (:pull:`566`) |
| 200 | +* Prevent automatic recursion into submodules. |
| 201 | + |
| 202 | + The user can enable the recursive submodule handling in the global git |
| 203 | + config. Bob does the update of submodules manually but some git invocations |
| 204 | + missed the proper arguments. |
| 205 | + |
| 206 | + (:issue:`568`) |
| 207 | +* Fixed parse failure for substitutions in disabled dependencies. |
| 208 | + |
| 209 | + If a dependency is disabled, all other variable substitutions in this |
| 210 | + dependency shall be skipped. That has been the case already, except the |
| 211 | + dependency name itself. No Bob will ignore name substitution failures as well |
| 212 | + if the dependency shall be skipped. |
| 213 | + |
| 214 | + (:pull:`575`) |
| 215 | +* Fixed command line color mode handling. (:issue:`578`) |
| 216 | +* String substitution now skips over unused substitution parts. |
| 217 | + |
| 218 | + Variable substitutions can have a default value (``${VAR-default}``) or an |
| 219 | + alternate value (``${VAR+alternate}``). The "default" and "alternate" parts |
| 220 | + can itself be comprised of variable/function substitutions. |
| 221 | + |
| 222 | + Now, if the default/alternate part is unused, it should be skipped |
| 223 | + altogether. Previously Bob always substituted them, even if they were unused. |
| 224 | + This was undesired because it caused constructs like:: |
| 225 | + |
| 226 | + ${VAR:+${VAR}} |
| 227 | + |
| 228 | + to fail which contradicts POSIX shell substitution behaviour which we try to |
| 229 | + follow. Now such parts are properly skipped. |
| 230 | + |
| 231 | + (:pull:`583`) |
| 232 | +* Fixed that git repositories in detached HEAD state are not moved to the attic |
| 233 | + if the repository already points to the commit in the recipe. (:pull:`584`) |
| 234 | +* Fixed crash on Windows WSL1. (:issue:`562`) |
0 commit comments