Feature: Index git tags with commits

[bdougie]

Type of feature

🍕 Feature

Current behavior

Currently we have awareness of commits and author ids. I think indexing tags as well will give us an opportunity to start identify authors that most frequently appear in a specific releases based on tags.

My solution is naive, but I'd love to chat through this idea.

Suggested solution

This might need a conversation, but here is my initial thought

1. Fetch recent tags during the baking process. We may want to limit this initially, to most recent 30 or a date. I know some projects could have 1000 tags.
2. Add column on commits for tags in the api.opensauced.pizza schema

Additional context

Do we have a better for connecting commits to tags?

Code of Conduct

• I agree to follow this project's Code of Conduct

Contributing Docs

• I agree to follow this project's Contribution Docs

[jpmcb]

This will introduce magnitudes of complexity so it'll be really important to understand the intent here.

From a git perspective, tags are just certain static commits within the version control scheme that denote important points in history.

Since tags can reference any arbitrary commit, they may reference headless commits, commits not on the main branch, commits within sub-modules, etc. But for most use cases, they reference commits on the main branch (usually some sort of release) and commits on important branches (like versioned branches that get their own releases and commits but are not based on the main branch).

Today, the pizza oven service indexes commits on the main branch only and explicitly ignores tags.

If we wanted to start indexing commits that accurately reference commits we have indexed, we'd probably also need to index all other branches and commits which opens its own can of worms. What happens when a branch is deleted? What happens when a branch is force pushed to or squashed on? What happens when tags are deleted?

Fetch recent tags during the baking process.

I don't believe tags have the concept of "recent" or "time" since they only reference points in the commit history. I.e., it'd be possible to create a tag that references a very old point in the git history but it wouldn't be denoted as the "newest" tag.

GitHub releases sort of makes this confusing since they use tags as reference points in history but are an extra decoration ontop of those tags which denote when that release happened, release notes, ability to add artifacts, etc.

[bdougie]

This will introduce magnitudes of complexity so it'll be really important to understand the intent here.

This is good insight and I don't the value is here yet. We had a design partner requesting insights into releases, but I think this may be better approached with our internal ETL service or Catsup app service.

The pitch was for tracking releases and seeing which contributors make the release and how often. Tags was a way to see releases outside of GItHub, but more the I think about it, we should solve this using releases and not tags.