Autoproj 2.9.0 / Autobuild 1.17.0

Important notes:

• automated build environments must add the apt_dpkg_update flag to their seed config. This flag controls automatic APT package update, see details in the new features below.

New features:

• Git imports can now refer to remote branches that are not under refs/heads/, for instance refs/pull//head on GitHub:

  - type: git
    branch: refs/pull/205/head
  

• Autoproj now complains about Git-LFS being missing only for packages that have it enabled
• Optionally update APT packages instead of only checking for their presence. There's a new question to enable/disable this feature at bootstrap time (or on upgrade to 2.9.0)
• Add the ability to install new repository to the system's package manager (for now only APT is supported). See this documentation for more details

User-facing Bugfixes:

• fix status --local
• fix -k to continue even if an update fails
• the pip system package should now be automatically installed when pip packages are required
• fixed handling of gems missing in the workspace if they are directly selected by the manifest (as opposition to being depended-upon by other packages). This was triggered by partial update/build (e.g. autoproj update <PACKAGE>)

New functionality for developers:

• autoproj is now exporting a JSON file to report on what was done during the last build, in .autoproj/build_reprot.json. This can be used in e.g. CI builds to report on what had been done.
• fixed computed package dependencies in post-update hooks when no packages are selected (e.g. autoproj update --config)

Bugfix release v2.8.8

Fixes:

• Fix installation when bundler is installed system-wide (#219)
• Fix autoproj test without arguments to run tests for all enabled packages (#221)

v2.7.0

New functionality

• Python package support. Autoproj installs the python package if there is a setup.py file, or use the package in-place (alike to Ruby packages) otherwise

Bugfixes

• fix reporting configuration errors with --tool (i.e. when building in vscode)
• ROS' package.xml will be loaded only if the use_package_xml flag is set on the package, and ignored otherwise. Loading package.xml unconditionally caused a lot of problem for otherwise working setups, because some packages ship a ROS package.xml but no Autoproj manifest.xml - the setup being done in the package sets, and/or because there are other non-catkin build tools that use package.xml, albeit with a different format than ROS. The catking_package helper allows you to setup a CMake package that use package.xml in one declaration.
• do not snapshot a package that is up to date in autoproj status, speeding up status quite a bit.
• add an entry for Ruby 2.5 built with rbenv

v2.6.1

Bugfixes:

• fix parsing bugs for ROS' package.xml

v2.6.0

Bugfixes

• resolve in a package set's imports field the same constants than in the version_control field. $AUTOPROJ_ROOT and constants defined within the package set and within the manifest are for instance available now (#185)

New experimental features:

• support ROS package.xml (manifest.xml takes precedence)
• support checking out all source packages in a subfolder of the main workspace root by setting the source configuration option

v2.5.1

Bugfixes:

• fix configuration not being written in some cases (#182)

v2.5.0

Bugfixes

• fix snapshot-related commands versions, commit and tag (#171)
• fix pip handling when env.sh has not explicitely been loaded.
• fix checking out a git-backed package with submodules when there is a tag, commit or a different branch than master
• make sure the git importer actually updates the references in remotes/

New/changed experimental CLI Commands

These commands have been created to support the integration of autoproj-based workspaces (a.k.a. Rock) in VSCode. See https://github.com/rock-core/rock-vscode

• the --tool option now summarizes the errors at the end
• exec: run a workspace executable, without needing to load env.sh first. E.g. $WORKSPACE_ROOT/.autoproj/bin/autoproj exec syskit run -rgazebo
• which: resolves an executable within the workspace's PATH, without loading env.sh first
• watch: auto-update the env.sh and cache files that are used by exec and which. This speeds up exec and which noticeably.

v2.5.0 Prerelease 1

Bugfixes

• fix snapshot-related commands versions, commit and tag (#171)
• fix pip handling when env.sh has not explicitely been loaded.
• fix checking out a git-backed package with submodules when there is a tag, commit or a different branch than master
• make sure the git importer actually updates the references in remotes/

New/changed experimental CLI Commands

These commands have been created to support the integration of autoproj-based workspaces (a.k.a. Rock) in VSCode. See https://github.com/rock-core/rock-vscode

• the --tool option now summarizes the errors at the end
• exec: run a workspace executable, without needing to load env.sh first. E.g. $WORKSPACE_ROOT/.autoproj/bin/autoproj exec syskit run -rgazebo
• which: resolves an executable within the workspace's PATH, without loading env.sh first
• watch: auto-update the env.sh and cache files that are used by exec and which. This speeds up exec and which noticeably.

2.4.0

Important Change:

• requires Ruby 2.1 or later
• released along with Autobuild 1.12.2 Changelog

Bugfixes:

• fix backtraces leaking to the user
• fix errors in the Yum and Zypper osdep managers (thanks @vbargsten, #158)

New functionality:

• git_server_configuration can now lazily resolve the configuration, which allows to
  essentially remove the gitorious.org definition in a backward-compatible way.
• cli: allow autoproj cache to cache a single package and its dependencies
• cli: added autoproj exec
• cli: added autoproj which
• cli: added OS dependency query to autoproj query

2.2.0

New features:

• Added --auto-exclude to build and update

Auto-exclusion deals with builds where a package can either not be checked out, or when its manifest.xml contains errors. The current behavior would be to fail, regardless of whether -k (--keep-going) is provided or not, as a valid version of the package is not available.

The old behavior is still the default, as it would be the expected behavior on a developer's workflow. However, in CI environments, it makes "meta-builds" (as e.g. rock.all) fail. Given that we can't control what people do with their packages, freezing the CI environment because of one misbehaving package is definitely not a good idea.

--auto-exclude will exclude packages like this. The failure or not of the whole build is still governed by exclusion rules: a package explicitly selected in the manifest, or a package that is part of a metapackage not marked as 'weak' will still fail.