Currently, any new automated commits require git commit logic
to be duplicated for each job. We can specify this behavior in a config,
making it much easier to add or change.
Depends on D7442
Details
Details
Diff Detail
Diff Detail
- Repository
- rABC Bitcoin ABC
- Branch
- ac-prep-commit
- Lint
Lint Passed - Unit
No Test Coverage - Build Status
Buildable 12740 Build 25563: Build Diff build-clang-tidy · build-diff · build-clang-10 · build-without-wallet Build 25562: arc lint + arc unit
Event Timeline
| contrib/source-control-tools/automated-commits.sh | ||
|---|---|---|
| 253 ↗ | (On Diff #23488) | I added this to the catch-all for now. If the COMMIT_TYPE doesn't exist, it will still error as expected. As more of these builds are migrated into the configuration, this switch-case will eventually collapse down to primarily this bit of logic. |
Comment Actions
Switched from update-manpages to update-seeds since D7446 is getting rid of update-manpages entirely
Comment Actions
You are build a Rube Goldberg machine. Just have some kind of automated patch script in which you can plug whatever code generation part you want.
The script checkout out the repo, make sure it is clean, etc...
Then it call the custom script. Gets a commit message and a set of changes in the repo out of it.
Commit all the changes using the message name, run smoke test, push.
| contrib/source-control-tools/automated-commits.sh | ||
|---|---|---|
| 271 | I'm highly skeptical of the fact that a build plan might end up being the best way to describe a serie of step that effectively generate a patch. If anything, what you do after to verify that the patch did not break the world is indeed a build plan, but generating the patch itself? | |