Changeset View
Changeset View
Standalone View
Standalone View
contrib/source-control-tools/automated-commits.sh
Show First 20 Lines • Show All 228 Lines • ▼ Show 20 Lines | then | ||||
exit 0 | exit 0 | ||||
fi | fi | ||||
git add "${MANPAGES_DIR}"/*\.1 | git add "${MANPAGES_DIR}"/*\.1 | ||||
git commit -m "${BOT_PREFIX} Update manpages" | git commit -m "${BOT_PREFIX} Update manpages" | ||||
;; | ;; | ||||
update-seeds) | |||||
TEAMCITY_DIR="${TOPLEVEL}"/contrib/teamcity | |||||
"${TEAMCITY_DIR}"/build-configurations.py --config "${TEAMCITY_DIR}"/automated-commits.yml "${COMMIT_TYPE}" | |||||
git add "${TOPLEVEL}"/contrib/seeds/nodes_main.txt | |||||
git add "${TOPLEVEL}"/contrib/seeds/nodes_test.txt | |||||
git add "${TOPLEVEL}"/src/chainparamsseeds.h | |||||
git commit -m "${BOT_PREFIX} Update seeds" | |||||
;; | |||||
update-timings) | update-timings) | ||||
"${DEVTOOLS_DIR}"/build_cmake.sh | "${DEVTOOLS_DIR}"/build_cmake.sh | ||||
pushd "${BUILD_DIR}" | pushd "${BUILD_DIR}" | ||||
ninja check-functional-extended | ninja check-functional-extended | ||||
TIMING_SRC_FILE="${TOPLEVEL}"/test/functional/timing.json | TIMING_SRC_FILE="${TOPLEVEL}"/test/functional/timing.json | ||||
mv timing.json "${TIMING_SRC_FILE}" | mv timing.json "${TIMING_SRC_FILE}" | ||||
popd | popd | ||||
Show All 17 Lines | update-timings) | ||||
popd | popd | ||||
git add "${TIMING_SRC_FILE}" | git add "${TIMING_SRC_FILE}" | ||||
git commit -m "${BOT_PREFIX} Update timing.json" | git commit -m "${BOT_PREFIX} Update timing.json" | ||||
;; | ;; | ||||
*) | *) | ||||
echo "Error: Invalid commit name '${COMMIT_TYPE}'" | TEAMCITY_DIR="${TOPLEVEL}"/contrib/teamcity | ||||
exit 10 | "${TEAMCITY_DIR}"/build-configurations.py --config "${TEAMCITY_DIR}"/automated-commits.yml "${COMMIT_TYPE}" | ||||
deadalnix: I'm highly skeptical of the fact that a build plan might end up being the best way to describe… | |||||
# If there is no change, we're done. | |||||
if [ -z "$(git status --porcelain)" ]; then | |||||
echo "There is nothing to commit because no changes were made." | |||||
exit 0 | |||||
fi | |||||
"${TOPLEVEL}"/contrib/source-control-tools/prepare-commit.py "${COMMIT_TYPE}" | |||||
;; | ;; | ||||
esac | esac | ||||
# Smoke tests to give some confidence that master won't be put into a bad state | # Smoke tests to give some confidence that master won't be put into a bad state | ||||
"${DEVTOOLS_DIR}"/smoke-tests.sh | "${DEVTOOLS_DIR}"/smoke-tests.sh | ||||
echo "Pushing automated commit '${COMMIT_TYPE}'..." | echo "Pushing automated commit '${COMMIT_TYPE}'..." | ||||
# Make sure master is up-to-date. If there is a merge conflict, this script | # Make sure master is up-to-date. If there is a merge conflict, this script | ||||
# will not attempt to resolve it and simply fail. | # will not attempt to resolve it and simply fail. | ||||
git fetch origin master | git fetch origin master | ||||
git rebase "${PARENT_COMMIT}" | git rebase "${PARENT_COMMIT}" | ||||
git push "${GIT_PUSH_OPTIONS[@]}" origin master | git push "${GIT_PUSH_OPTIONS[@]}" origin master |
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?