1. 27 Feb, 2019 8 commits
  2. 26 Feb, 2019 1 commit
  3. 25 Feb, 2019 1 commit
  4. 23 Feb, 2019 3 commits
  5. 21 Feb, 2019 4 commits
  6. 20 Feb, 2019 1 commit
  7. 19 Feb, 2019 1 commit
  8. 15 Feb, 2019 1 commit
  9. 14 Feb, 2019 1 commit
  10. 06 Feb, 2019 1 commit
  11. 05 Feb, 2019 1 commit
  12. 04 Feb, 2019 2 commits
    • Matthew Sykes's avatar
      [FAB-12942] use logfmt format for log fields · 2a8127f0
      Matthew Sykes authored
      
      
      Change-Id: Ibbbf4f55bd42a0914edc4b247c391e020b3a68a4
      Signed-off-by: default avatarMatthew Sykes <sykesmat@us.ibm.com>
      2a8127f0
    • yacovm's avatar
      [FAB-13843] Fix cclifecycle test flake · 8a887975
      yacovm authored
      
      
      FAB-13471 Introduced a UT that does several (3) background listener updates.
      The test only waits for the listener updates to fire, but there is a log invocation
      that happens immediately afte the listener fires.
      
      The next test that runs, overwrites the logger's reference and thus a data race
      occurs (the previous test's spawned goroutine reads the logger's reference to write
      the log, while the next test replaces the logger reference.
      
      Fixed it by making the test wait until the log of the first test, logs
      the last message that is logged during the listener dispatch - 3 times.
      
      Ideally we'd have a logger instance for the production struct as a field,
      but this solution is far easier and has no production code change, so its
      surface area is smaller.
      
      Change-Id: Ia7ef144ae8574783b2b7a4925f47b51e966f8942
      Signed-off-by: default avataryacovm <yacovm@il.ibm.com>
      8a887975
  13. 28 Jan, 2019 1 commit
  14. 25 Jan, 2019 1 commit
  15. 24 Jan, 2019 1 commit
  16. 23 Jan, 2019 2 commits
  17. 21 Jan, 2019 1 commit
    • yacovm's avatar
      [FAB-13471] lifecycle to handle multiple updates · 908739e0
      yacovm authored
      
      
      The ledger calls several HandleChaincodeDeploy for each update
      but only a single ChaincodeDeployDone after all invocations
      to HandleChaincodeDeploy were made.
      
      The current implementation only supported a single update,
      and as a result - a second ChaincodeDeployDone will get stuck
      writing to a channel.
      
      This change set makes the Lifecycle in core/cclifecycle
      to be able to handle any number of updates in a single block.
      
      Change-Id: I1d85018af398bd5cb968e42031986a999f6be444
      Signed-off-by: default avataryacovm <yacovm@il.ibm.com>
      908739e0
  18. 18 Jan, 2019 1 commit
    • pama-ibm's avatar
      [FABCI-258] Fixed doc link · f118f2bc
      pama-ibm authored
      
      
      Fixed the docs badge
      link to point to the release branch
      of the doc. Also added a link to the
      Hyperledger Fabric rocket chat
      
      Change-Id: Icbe64888496ffda046d4e2668bd0caf100875454
      Signed-off-by: default avatarpama-ibm <pama@ibm.com>
      f118f2bc
  19. 17 Jan, 2019 1 commit
  20. 16 Jan, 2019 2 commits
  21. 15 Jan, 2019 2 commits
  22. 14 Jan, 2019 3 commits