DAOS-623 build: git commit template
The proposed git commit template provides all available pragmas for easy and quick Jenkins build configuration/tuning.
It is always used when the -m parameter is not provided to github commit command.
Run git config commit.template ./.gitcommittemplate.txt to install the template.
Steps for the author:
- [x] Commit message follows the guidelines.
- [x] Appropriate Features or Test-tag pragmas were used.
- [x] Appropriate Functional Test Stages were run.
- [ ] At least two positive code reviews including at least one code owner from each category referenced in the PR.
- [x] Testing is complete. If necessary, forced-landing label added and a reason added in a comment.
After all prior steps are complete:
- [ ] Gatekeeper requested (daos-gatekeeper added as a reviewer).
Ticket title is 'Generic ticket for minor code cleanup and improvement' Status is 'Resolved' Labels: 'request_for_2.6.4,request_for_2.6.5,scrubbed_2.6.5' https://daosio.atlassian.net/browse/DAOS-623
I like the idea of this, but a concern that I have is that it creates another place that needs to be maintained when pragmas and components change, which could lead to it becoming stale. I think it's a great tool, but would it be better simply documented in a wiki and shared with the team? Just a thought.
I like the idea of this, but a concern that I have is that it creates another place that needs to be maintained when pragmas and components change, which could lead to it becoming stale. I think it's a great tool, but would it be better simply documented in a wiki and shared with the team? Just a thought.
I think that the problem is we have too many places where we document Pragmas, Jenkins parameters, etc. And the wiki itself is too far from the source code. The main purpose of this PR is to provide a simple checklist to disable/enable particular tests in a very easy way.
In the future anyone who modify the default tests configuration (I guess in Jenkins file) should also adjust this template file.
I like the idea of this, but a concern that I have is that it creates another place that needs to be maintained when pragmas and components change, which could lead to it becoming stale. I think it's a great tool, but would it be better simply documented in a wiki and shared with the team? Just a thought.
I think that the problem is we have too many places where we document Pragmas, Jenkins parameters, etc. And the wiki itself is too far from the source code. The main purpose of this PR is to provide a simple checklist to disable/enable particular tests in a very easy way.
In the future anyone who modify the default tests configuration (I guess in Jenkins file) should also adjust this template file.
I think part of the problem is most pragmas are controlled by pipeline-lib. So when they change, presumably there is a pipeline-lib PR, and then someone has to come update this repo as well. Which is in addition to already having to update the other locations.