Path filtering should produce a commit ID based on the last commit to touch the filtered paths

[Tobias-08]

Hi,
we are using pathFilter to increment versions only for affected components in a monorepo structure. This is working fine regarding the height but the behavior of commit ID for non-public releases is different to what (at least) I expected.

Given a monorepo with /componentA and /componentB subdirectories and according pathFilter configurations. Assuming a commit in /componentA-subfolder:

• Current behavior
  • height+1 and new commit ID for componentA (expected)
  • height+0 for componentB (expected), but also new commit ID (not expected)
• Expected behavior
  • commit ID only changes if the commit falls in the range of the pathFilter

Does this make sense or am I missing something?

[AArnott]

Interesting that you bring this up now, because only this week someone internally on my own team seemed to have hit this too. I agree the commit ID (including both its direct appearance when PublicRelease=false and also its indirect presence in the 4th integer of certain versions) should be the last commit to have touched the filtered paths.

@saul, how do you feel about this? If you agree, do you think you could find time to make this enhancement? (it doesn't have to be immediately).

[AArnott]

Maybe we should only use that path-filter based commit ID for package versions, but keep the real (HEAD) commit ID in other places like the AssemblyInformationalVersion attribute. I'm open to suggestions here.

[Tobias-08]

I would prefer using the same (path-filter based) commit ID in all versions in order to have a consistent behavior. That said my primary focus is the package version so that a differing approach that might be better for the majority is fine for me, too.