[FEATURE] Be able to generate changelog for a monorepo package

[maniolias]

Is your feature request related to a problem? Please describe.
In a monorepo context we cannot generate a changelog for a specific package. The aim of this feature is to be able to genrate only changelog body of sub-repo for instance to be able to push it on a release in github for instance.

Describe the solution you'd like
For instance like we can do in get-version:
cog changelog --package gill-app

Describe alternatives you've considered
For now we stick in using a custom bash script to extract latest changelog changes

#!/bin/bash

if [ ! -f "$1" ]; then
  echo "Le fichier $1 n'existe pas."
  exit 1
fi

separator_count=0
extract_data=false

while IFS= read -r line; do
  if $extract_data && [[ "$line" != "- - -" ]]; then
    echo "$line"
  fi

  if [[ "$line" == "- - -" ]]; then
    ((separator_count++))
    if ((separator_count == 1)); then
      extract_data=true
    elif ((separator_count == 2)); then
      break
    fi
  fi
done < "$1"

Usage: ./changelog-extract.sh ./crates/gill-app/CHANGELOG.md

But it's not extensible and we cannot leverage --at and other arguments of cog changelog

[JamesXNelson]

Adding my +1 to this. Being able to bump a single package in a monorepo without being able to extract the changelog just for that package makes github releases for individual packages ~impossible (without the above workaround: thanks for that!)

[ABWassim]

Hey,

I've been trying to tackle this feature a couple of weeks ago but I'm really struggling to find the right strategy.

I tried applying the same algorithm used in the get_release_range method but the problem is that the get_commit_range function falls back to the latest tag if pattern.from isn't defined, (which is the case when the pattern is created in get_release_range), but it doesn't necessary match a tag that belongs to our package (for example the tag of another package).

Therefore we would have to manually find the closest tag of pattern.to that "belongs" to the package, but there are so many fallbacks and possible cases that I kind of get confused.

Ideally we would need to list all the tags of the package, but from my reasearch this isn't possible with libgit2 with a low complexity (aka. listing all the tags + filtering).

@oknozor Any idea ? I also saw you're doing some refactor on Revspec, maybe I can wait for it as well :)

[oknozor]

Hi @ABWassim, I agree the current tag lookup and revspec implementation is not so ergonomic.
Good news is, the revspec refactor should solve your issue:

cocogitto/src/git/tag.rs

Lines 21 to 48 in 74e3675

	impl<'a> TagLookUpOptions<'a> {
	/// Perform a tag lookup with pre-release tag included
	pub fn include_pre_release(mut self) -> Self {
	self.include_pre_release = true;
	self
	}
	/// Perform a tag lookup, keeping only tags for the given package
	pub fn package(package: &'a str) -> Self {
	let mut opts = Self::default();
	opts.package_name = Some(package);
	opts.packages_only = true;
	opts.include_packages = true;
	opts
	}
	/// Perform a tag lookup, keeping only packages tags.
	pub fn packages_only(mut self) -> Self {
	self.packages_only = true;
	self
	}
	/// Perform a tag lookup, mixing non package and package tags.
	pub fn include_packages(mut self) -> Self {
	self.include_packages = true;
	self
	}
	}

I am going to take some time to finish this. I will be off next week and this PR will probably need a breaking change on the revspec arg parsing. But you can start from this branch and see if it solve your current problem with tag lookup.

Let me know how it goes and if anything need to be changed there.

[ABWassim]

Thanks @oknozor ! I'll have a look at this