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

Jump to bottom

Retry-on-failure for submodule doesn't seem to work #39051

Closed
alexcrichton opened this issue Jan 14, 2017 · 2 comments
Closed

Retry-on-failure for submodule doesn't seem to work #39051

alexcrichton opened this issue Jan 14, 2017 · 2 comments
Labels
A-spurious Area: Spurious failures in builds (spuriously == for no apparent reason)

Comments

@alexcrichton
Copy link
Member

I've seen a failure like https://travis-ci.org/rust-lang/rust/jobs/191773475 twice now where it looks like:

  1. The initial submodule clone fails due to a standard error we've been seeing a lot spuriously on Travis.
  2. The submodule clone was auto-retried due to us wrapping it in travis_retry
  3. Later on the build fails because the rust-installer submodule wasn't actually checked out

I have no idea why git submodule update --init doesn't seem to be updating the rust-installer submodule. It even seems to be cloning it, just not checking it out.

Presumably all other submodules succeeded to get cloned because the whole build succeeded otherwise...
@alexcrichton alexcrichton added the A-spurious Area: Spurious failures in builds (spuriously == for no apparent reason) label Jan 14, 2017
@alexcrichton alexcrichton mentioned this issue Jan 14, 2017
Merged
@aidanhs aidanhs mentioned this issue Jan 14, 2017
Merged
bors added a commit that referenced this issue Jan 15, 2017
@bors
Auto merge of #39055 - aidanhs:aphs-deinit-before-init, r=alexcrichton
20ba64d 
If submodule init fails, try from scratch

See #39051

I wonder if the cause could be some strange not-quite-checked-out state in a submodule. Try and fix this by force deinitialising everything before initialising (this will not throw away downloaded objects, git will skip them on the next attempt at cloning).

r? @alexcrichton
@brson
Copy link
Contributor

brson commented Jan 18, 2017

Should effectively be fixed by #39055 but maybe we should wait for a while before closing.

@alexcrichton
Copy link
Member Author

Oh right I actually saw this happen (saw the retry and then saw this logic kick in). The rust-installer build then finished successfully later. As a result I'm going to close this as I think it's taken care of (thanks @aidanhs!) and we can always reopen if it turns out to still be there.

@aidanhs aidanhs mentioned this issue Apr 12, 2017
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
A-spurious Area: Spurious failures in builds (spuriously == for no apparent reason)
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@alexcrichton @brson