Open adambirds opened 1 year ago
I'm unable to determine whether this will be added or not. However, if the dependabot team accepts it, would you consider submitting a PR for it? Although it's not necessary, it would speed up the process.
Furthermore, have you thought about excluding dependabot pull requests from your linting in the meantime? While it may not be the optimal solution, it should still help you unblock the process while the feature is being debated
I have temporarily done that. I'd be happy to do a PR but I'm not a ruby person so don't know where to start but if you could point me in the direction of which files etc would need updating i may be able to figure it out. Thanks @yeikel
I have temporarily done that. I'd be happy to do a PR but I'm not a ruby person so don't know where to start but if you could point me in the direction of which files etc would need updating i may be able to figure it out. Thanks @yeikel
If I am not mistaken, the logic you're looking for should be here
In this example, I believe that you'd need to extend MessageBuilder
to accept a new optional constructor argument such as commit_message_suffix
And then use it within the commit message builder as the first parameter like this :
def commit_message
message += commit_subject + "\n\n"
message += commit_message_intro
message += metadata_links
message += "\n\n" + message_trailers if message_trailers
message += commit_message_suffix if commit_message_suffix
message
Note that this is just an example and how I would do it. I do not know if the dependabot team would accept it as described
Before starting to work on it, it is advisable to wait for confirmation from the dependabot team that they are willing to review and accept the new feature into core.
Since this is a new addition to dependabot-core and not just a bug fix, implementing it is only part of the work required to make it available in the public dependabot service. This implies that the new feature must be integrated into the dependabot schema, documented, and tested, among other things before it can reach general availability for you to use it.
It is not impossible, and your wiliness to help is appreciated, I am just trying to be honest with you so that you can keep your expectations and timelines realistic.
I hope that the explanation helps, and thank you again.
Thanks for the detailed explanation @yeikel. Happy to wait for feedback from the dependabot team first. On having a poke at that file you linked, it seems quite similar to Python so that makes me hopeful it wouldn't be too steep of a learning curve which is a relief. I didn't realise the two languages shared a similar look.
And not sure if it came across clear in the first post. I'd like the suufix to be added to the first line of the commit message rather than right at the end of the whole message as well which guessing may complicate it further.
And not sure if it came across clear in the first post. I'd like the suufix to be added to the first line of the commit message rather than right at the end of the whole message as well which guessing may complicate it further.
Can you share some examples?
@yeikel So this is one of my current Dependabot commit messages:
build(deps-dev): bump black from 22.3.0 to 23.3.0
Basically I would like this to be:
build(deps-dev): Bump black from 22.3.0 to 23.3.0.
So what I need to be able to change is to be able to add a suffix to the commit message title so that can have it end with a period. Another thing is that I need to be able to capitalise the first word after the colon.
I have attached a screenshot of a list of my commits so you can see more of the messages which meet my linters.
Thank you for the examples.
Have you considered using this transformation at merge time in the meantime?
If you use squash
commits, you'll get the opportunity to change the final commit message and you might me able to build a simple script to do this using the github cli or the scripts action
I understand that is not the solution you're looking for, but it'll be easier for you.
To be honest it doesn't really work for me as I prefer a proper rebase workflow to keep the entire git history. I think at the moment I'd rather just exclude dependabot commits from the linters and then see how this progresses.
To be honest it doesn't really work for me as I prefer a proper rebase workflow to keep the entire git history. I think at the moment I'd rather just exclude dependabot commits from the linters and then see how this progresses.
I meant to squash only the dependabot commits. Generally, they're always 1 commit
Hi, any update on this issue ? We need it it for [skip ci] is certain case ;)
Hi, any update on this issue ? We need it it for [skip ci] is certain case ;)
Did you consider what I suggested above?
Is there an existing issue for this?
Feature description
I do believe this has been requested before in #533 as well as #1446 however both issues are closed. Not being able to set a suffix is causing my git commit message linters to fail.
A similar request is #2091 however that is for a description suffix whereas this is the actual commit message I would like to be able to set this on.