chore: adapt component name for v2 libraries#20004
Conversation
Because `include-component-in-tag` in tag was set that the v2 was in the component name release-please would search for a tag like `pubsub/v2/v2.6.0` which is incorrect. This caused more commits to show up than desired because it falls back to search last X commits in a path.
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
codyoss
added
the
do not merge
|
I am researching this more. I will leave do not merge on until I am sure this is the correct approach. |
shollyman
left a comment
shollyman
left a comment
There was a problem hiding this comment.
This is where my release please knowledge is weaker. Presumably a component can have two release artifacts?
I'm mostly wanting to make sure we don't end up with unusual conflicts or behavior between the v1 and v2 modules for these respective projects, or at least we know what we need to do operationally to accomodate it.
|
@shollyman I think I will need to do a little work here and get back to you. This change is needed so the Go tags are correct but you are right about the branch names would conflict. I am going to file an issue for this to find a way we can support this go pattern. I created googleapis/release-please#2817 for tracking |
2 participants
Because
include-component-in-tagin tag was set that the v2 was in the component name release-please would search for a tag likepubsub/v2/v2.6.0which is incorrect. This caused more commits to show up than desired because it falls back to search last X commits in a path.Related: #20002