Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

add a few comments for the toolstate stuff #1

Merged
merged 1 commit into from
Jul 18, 2019
Merged

add a few comments for the toolstate stuff #1

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
12 changes: 8 additions & 4 deletions src/ci/docker/x86_64-gnu-tools/checktools.sh
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -41,7 +41,7 @@ check_tool_failed() {
}

# This function checks that if a tool's submodule changed, the tool's state must improve
verify_status() {
verify_submodule_changed() {
echo "Verifying status of $1..."
if echo "$CHANGED_FILES" | grep -q "^M[[:blank:]]$2$"; then
echo "This PR updated '$2', verifying if status is 'test-pass'..."
Expand All @@ -66,7 +66,7 @@ verify_status() {
check_dispatch() {
if [ "$1" = submodule_changed ]; then
# ignore $2 (branch id)
verify_status $3 $4
verify_submodule_changed $3 $4
elif [ "$2" = beta ]; then
echo "Requiring test passing for $3..."
if check_tool_failed "$3"; then
Expand All @@ -75,7 +75,9 @@ check_dispatch() {
fi
}

# list all tools here
# List all tools here.
# This function gets called with "submodule_changed" for each PR that changed a submodule,
# and with "beta_required" for each PR that lands on beta/stable.
status_check() {
check_dispatch $1 beta book src/doc/book
check_dispatch $1 beta nomicon src/doc/nomicon
Expand All @@ -85,7 +87,8 @@ status_check() {
check_dispatch $1 beta rls src/tools/rls
check_dispatch $1 beta rustfmt src/tools/rustfmt
check_dispatch $1 beta clippy-driver src/tools/clippy
# these tools are not required for beta to successfully branch
# These tools are not required on the beta/stable branches.
# They will still cause failure during the beta cutoff week, see `src/tools/publish_toolstate.py` for that.
check_dispatch $1 nightly miri src/tools/miri
check_dispatch $1 nightly embedded-book src/doc/embedded-book
check_dispatch $1 nightly rustc-guide src/doc/rustc-guide
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@kennytm should we say that the list of "nightly" tools here and of REGRESSION_OK tools in publish_toolstate.py should be in sync?

(Ideally they could source from the same data but I am not sure what a good way to do that would be.)

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes ideally these should be in sync.

Expand All @@ -97,6 +100,7 @@ status_check() {
status_check "submodule_changed"

CHECK_NOT="$(readlink -f "$(dirname $0)/checkregression.py")"
# This callback is called by `commit_toolstate_change`, see `repo.sh`.
change_toolstate() {
# only update the history
if python2.7 "$CHECK_NOT" "$OS" "$TOOLSTATE_FILE" "_data/latest.json" changed; then
Expand Down
4 changes: 4 additions & 0 deletions src/ci/docker/x86_64-gnu-tools/repo.sh
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -62,6 +62,10 @@ commit_toolstate_change() {
MESSAGE_FILE="$1"
shift
for RETRY_COUNT in 1 2 3 4 5; do
# Call the callback; this will in the end call `change_toolstate` from
# `checktools.sh` if we are in the `auto` branch (pre-landing) or
# `src/tools/publish_toolstate.py` if we are in the `master` branch
# (post-landing).
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@kennytm is this correct? I am not entirely sure about this.

The call with publish_toolstate.py is from somewhere in the CI config, which took me forever to find.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes.

(The call from CI is .azure-pipelines/master.yml, you could git grep /repo.sh to find this. Though the comment above still refers to Travis 😓)

"$@"
# `git commit` failing means nothing to commit.
FAILURE=0
Expand Down