Add option to filter out commits by title or content with a regex

[sezaru]

Nowadays it is getting common for a git repository to have more than one project inside of it. For example, in my company we have a repo that has 2 elixir projects and one frontend/angular one.

That means that people will push commits to different projects in the same repo, so I need a way to filter out commits that are not related to the specific project I'm working on.

In our case, normally our commits will start with the project name, for example:

Backend: Did something
Frontend: Applied something else

It would be great if I could create rules in git_ops that will tell it to just add commits to my changelog when the title starts with Backend via a regex.

Since this lib expects conventional commits, maybe another way of achieving the same would be to refex the content of the commit instead for some keyword?

[zachdaniel]

I'd be open to adding that for scopes, i.e type(scope): message?

[sezaru]

Isn't the scope used more to features of the project instead of being the project itself?

What about filtering by footers as that is something that is supported by the spec?

For example:

feat:my commit

PROJECT: backend

That would also allow to set multiple projects per commit in case my commit changes more than one (ex. a change to both the backend project and the frontend one):

feat:add new api

PROJECT: backend
PROJECT: frontend

[zachdaniel]

Yeah, you're right, we should do it off of something in the body. What if we did it more generically, via tags?

TAGS: backend, security, ...

Then later we can actually potentially hook more things off of those tags? Like grouping things by certain tags in changelogs, hiding/showing them, that kind of thing.

[zachdaniel]

Then you could say mix git_ops.release --include-tags backend

[sezaru]

Yeah, I agree, using tags seems better since it is more generic and will be possible to use it in multiple scenarios

[zachdaniel]

awesome. I won't have time to add this, but PRs are welcome :)

[sezaru]

So, I created a fork to work on this, but I'm seeing some odd things regarding the parser that I'm not sure it's broken or I'm just doing something wrong.

For example, if I pass this commit text to Commit.parse

GitOps.Commit.parse("feat: test_breaking\n\nBREAKING CHANGE: bla bla bla\nTAGS: test_git_ops")

I expect to get somethin like this

{:ok, [
  %GitOpts.Commit{
    type: "feat",
    scope: nil,
    message: "test_breaking",
    body: "BREAKING CHANGE: bla bla bla\nTAGS: test_git_ops",
    footer: nil,
    breaking?: false
  }
]}

But what I get is this:

{:ok,
 [
   %GitOps.Commit{
     type: "feat",
     scope: nil,
     message: "test_breaking",
     body: "BREAKING",
     footer: nil,
     breaking?: false
   },
   %GitOps.Commit{
     type: "CHANGE",
     scope: nil,
     message: "bla bla bla",
     body: nil,
     footer: nil,
     breaking?: false
   },
   %GitOps.Commit{
     type: "TAGS",
     scope: nil,
     message: "test_git_ops",
     body: nil,
     footer: nil,
     breaking?: false
   }
 ]}

Is this correct? The fact that the struct name is Commit but its parse splits one commit into "three" commits is kinda odd to me.

[zachdaniel]

Hmmmmm....yeah, so there might be some trouble here. We added a feature to pick up multiple commit messages from a single commit message, and it looks like it can't tell the difference between the footer and a new commit :(

I'm not sure what the solve is here TBH

[sezaru]

I have a POC of the filter working assuming these types of commits. I guess I can push it as a PR with tests so if that issue is fixed in the future, the test will break and we can just refactor it then

[zachdaniel]

Lets see the code :D