Support updated DroidDoc #274
Merged
Conversation
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
…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.
Contributor
|
This should include a bump to dotnet/java-interop@b4e151e. |
Contributor
Author
|
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.
Sign up for free
to 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).