Elasticsearch-net: Integrate diffing into build

Created on 30 Jan 2019  路  7Comments  路  Source: elastic/elasticsearch-net

Generate diff artifact as part of es.net build script.

  • Alert if Type="Deleted" or Type="Modified" is present
  • Attempt to de-duplicate erroneous Type="Modified" on types
  • Potentially filter on Modified and Deleted to aid human-check
Feature

Most helpful comment

We use: https://github.com/nullean/AssemblyDiffer which handles TFM's as well.

It allows us to compare the current build assemblies with a version on nuget.

The trouble is we need to feed that tool previous Nuget versions manually since depending on what branch we are we need a different version to compare against

| branch | version | action |
|---------|----------|---------
| 5.x | latest 5.xon nuget.org | fail if breaking |
| 6.x | latest 6.x on nuget.org | fail if breaking |
| 7.x | latest 7.x on nuget.org | fail if breaking |
| master | latest on nuget.org | break all the things! |

The version resolution requires investigating how Nuget.Client and its N auxialiary packages stitch together, things were a tad easier when it was OData. We currently use the v2 OData endpoints and but they've been deprecated for years now.

All 7 comments

What's the desired outcome? If you are after a feedback loop to inform you about potential breaking API changes to type signatures then check out this pattern

https://github.com/reactiveui/ReactiveUI/tree/master/src/ReactiveUI.Tests/API

ApiApprovalTests.cs is executed per TFM, generates the diff and compares against blessed aka ApiApprovalTests.Testing.[TFM].approved.txt which is checked into git. As this is a unit test it breaks the build upon incoming PR's if the surface changes. It's not 100% perfect because behavior of an API isn't checked _but_ over at ReactiveUI we have found that it greatly reduces the burden of reviewing PR's and is an excellent safe guard.

ps. this also means the history of the API surface for the entire library is version controlled in a text file that's super easy to git history.

We use: https://github.com/nullean/AssemblyDiffer which handles TFM's as well.

It allows us to compare the current build assemblies with a version on nuget.

The trouble is we need to feed that tool previous Nuget versions manually since depending on what branch we are we need a different version to compare against

| branch | version | action |
|---------|----------|---------
| 5.x | latest 5.xon nuget.org | fail if breaking |
| 6.x | latest 6.x on nuget.org | fail if breaking |
| 7.x | latest 7.x on nuget.org | fail if breaking |
| master | latest on nuget.org | break all the things! |

The version resolution requires investigating how Nuget.Client and its N auxialiary packages stitch together, things were a tad easier when it was OData. We currently use the v2 OData endpoints and but they've been deprecated for years now.

Closing this as this change has now been made in 6.x and 7.x. For example

> build skipdocs skiptests
> build diff "nuget|NEST.JsonNetSerializer|6.6.0|netstandard2.0 directory|../../build/output/Nest.JsonNetSerializer/netstandard2.0"

This will

  1. pull down the Nest.JsonNetSerializer 6.6.0 nuget package and its dependent packages
  2. compare all matching assembly names in the package and dependent packages with those in the ../../build/output/Nest.JsonNetSerializer/netstandard2.0 build output directory. In this instance, it will compare Elasticsearch.Net, Nest and Nest.JsonNetSerializer
  3. output the diff XML for each to build/output

We can aim to make this even easier to run in future so that you can just call something like

build diff "nuget|6.x|netstandard2.0"

to compare local compiled with the latest 6.x released version.

@russcam I think we should leave this open until it's part of build release <VERSION>. Right now we can call it easily from the command line but it's quite a mental chore composing the right arguments and finding the previous version to diff against

Also build canary which the PR's run, ideally these fail when diff target introduces a breaking change (depending on the branch)

Could we open two new issues for those, and keep the scope of this to including as a build target?

I'm down that with that :+1:

Was this page helpful?
0 / 5 - 0 ratings