sbt-trickle 0.2.5

Minor patch to log the reasons for ignoring a repository when updating. Or,
to put another way, log a reason for every repository in trickleOutdatedRepositories
that is not present in trickleUpdatableRepositories.

sbt-trickle 0.2.4

This is the last release before a break in API, so I did as
much as I could without the breaking changes.

• Resolve artifacts transitively, by default

  trickelIntransitiveResolve setting can override it to the
  former behaviour, for faster resolutions.

• trickleLogUpdatableRepositories

  This is the default implementation for trickleCreatePullRequests.
  It is now being exposed as a task so it can be used even
  after overriding that other task.

• trickleSaveGraph <filename.dot>

  Save the build graph as a dot file. Still working on the
  build graph format, though it is in a pretty good state. It
  might not work for everyone, though.

• trickleOpenGraph

  If you have "graphviz" installed and "open image.png" will
  display and image, then this will do the whole job for you.

• Working dry mode

  Dry mode was used on git, and not consistently, but not on
  PR creation. Now it's working properly.

• Github PR pagination

  Looking up pull requests was not doing pagination, and thus
  would miss PRs in repositories with large numbers of them.
  Mind you, the functionality this is supporting will go away
  in the next release, though it will come back later as a
  fully automated github pr creation.

• trickleGitReset

  I've had to figure out why something happened at one point,
  and the lengths I had to go to to do so inspired me to add
  this. Now I can just reset the local metadata repository
  to whatever commit I want, and use trickleOpenGraph to
  see what was going on.

• trickle{Outdated,Update,UpdateSession}Dependencies

  After introducing trickleCheckVersion in the previous
  release, it became suddenly obvious that the target
  repository is best suited to update its own dependencies,
  instead of having every repository needing to know how
  every other repository does that. Fine in homogenous
  environments, not so fine otherwise.

  The API was tricky, though. In the end, what we have is
  trickleOutdatedDependencies, which will list all of
  a repositories dependencies that need updating according
  to the metatada repository. That can then be used to
  implement trickleUpdateDependencies per repository,
  and call that when creating a pull request.

  The default implementation is trickleUpdateSessionDependencies,
  which is more useful on its own. It updates the
  dependencies on the session, so you can run compile
  and test mima compatbility and whatever else you want
  before actually making any changes, or before committing,
  etc. It will not save the session, so, by default,
  trickleUpdateDependencies doesn't save the changes
  either. You can save the session, but that mechanism
  is very limited.

• Better logging

  Both info and debug. On the info log side, whenever
  a repository updates itself (that is, pushes a change
  to the metadata repository), it will show the commit hash.
  That makes it easier to find the state of the repository
  from the build log.

  On the debug side, git gained a lot of debug logs, but
  BuildTopology gained the most, all in one place:
  the algorithm that figures out what repositories need to
  be updated. If you look at the debug logs for that, you'll
  now see extensive information about what it is looking at,
  what it is doing.

• Less bugs

  Some of them introduced between 0.2.3 and 0.2.4, granted.
  None of the bugs present in the previous release would
  show up under normal circumstances -- that is, a build
  running from a clean state. But if you do trickle things
  without running clean, it didn't always do the right
  thing.

sbt-trickle 0.2.3

This adds trickleCheckVersion. This task doesn't use the metadata repository
in any way. Instead, given a list of dependencies and versions to check, it
verifies that they all match what the repository current dependencies are.

The need for this became apparent when we saw trickle trying to update
repositories that had already been updated, and it turned out that the version
for one particular dependency was hard coded and, thus, ignoring the versions
file.

This allows builds to introduce a sanity check before actually creating a
pull request for an update, and signal unmanaged dependency versions.