Uh oh!
There was an error while loading. Please reload this page.
Support updated DroidDoc - #274
Merged
Merged
Conversation
…put. It seems to add java.util.Hashmap#put() override, which does not affect the public API.
Since there is no documentation component yet, it is actually generated with API Level 24 docs, so it lacks parameter names for newly added abstract methods that class-parse cannnot extract. But there is only one method that falls to the issue.
Note that this task is not functional enough to support javadocs correctly as it does not distinguish doclet type while it pretends to be able to.
jonpryor
commented
Oct 20, 2016
Contributor
This should include a bump to dotnet/java-interop@b4e151e. |
atsushieno
commented
Oct 21, 2016
ContributorAuthor
bumped. |
radical pushed a commit
that referenced
this pull request
May 8, 2018
Our desired build behavior is as follows: - **Green Build**: Everything compiles, and all unit tests pass. - **Red Build**: Everything *doesn't* compile. - **Orange/Unstable Build**: Everything compiles, but there is a unit test failure. The rationale for supporting Unstable builds is that oftentimes the CI system won't upload build artifacts if the build fails, and even if there are unit test failures, the build artifacts may otherwise be suitable for testing other bug fixes. (For example, the xamarin-android Jenkins job was recently failing because the network tests were hitting a TLS 1.2 site which had expired SSL certificates. This wasn't a bug in the source code or the unit tests, but the test infrastructure. This is not a Bad build.) Unfortunately, the Java.Interop tests on VSTS were not following this ideal, as unit test failures were resulting in a *green* (!) build. This happened because the `RunTests` target set `ContinueOnError="True"` on the `<Exec/>` for `nunit-console.exe`, and VSTS was only using `msbuild` exit status to determine success/failure. (Even though VSTS *found test failures* in the NUnit outputs, it still flagged the *overall* build as "good", which are *not* the semantics we wanted.) To get our desired behavior on VSTS, we have to: - Make sure our call to NUnit returns a failing exit code - Set the "Continue on Error" option in VSTS - Add a step at the end of our build definition in VSTS to fail the build if any issues occurred To make this work, we have to change our `<Exec />` task usage to use `ContinueOnError="ErrorAndContinue"`. (We *want* it to continue on error, so that *all* unit tests are executed, *even if* failures are detected.) Finally, add `Resource.designer.cs` to `.gitignore` to match the xamarin-android repo.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
It is recommended to NOT MERGE without merging dotnet/java-interop#96 (you can, but that would result in inconsistency).
The relevant Java.Interop PR is necessary to add support for API Level 25 (consistently in the future).