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.

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 task to run forbiddenapis using cli #32076

Merged
merged 14 commits into from
Aug 13, 2018

Conversation

alpar-t
Copy link
Contributor

@alpar-t alpar-t commented Jul 16, 2018

Add a task that offers an equivalent check to the forbidden APIs plugin,
but runs it using the forbiddenAPIs CLI instead.

This isn't wired into precommit first, and doesn't work for projects
that require specific signatures, etc. It's meant to show how this can
be used. The next step is to make a custom task type and configure it
based on the project extension from the pugin and make some minor
adjustments to some build scripts as we can't bee 100% compatible with
that at least due to how additional signatures are passed.

Notes:

  • there's no --target for the CLI version so we have to pass in
    specific bundled signature names
  • the cli task already wires to runtimeJavaHome
  • no equivalent for failOnUnsupportedJava = false but doesn't seem to
    be a problem. Tested with Java 8 to 11
  • there's no way to pass additional signatures as URL, these will have
    to be on the file system, and can't be resources on the cp unless we
    rely on how forbiddenapis is implemented and mimic them as boundled
    signatures.
  • the average of 3 runs is 4% slower using the CLI for :server.
    ( ./gradlew clean :server:forbiddenApis vs ./gradlew clean :server:forbiddenApisCli)
  • up-to-date checks don't work on the cli task yet, that will happen
    with the custom task.

See also: #31715

Add a task that offers an equivalent check to the forbidden APIs plugin,
but runs it using the forbiddenAPIs CLI instead.

This isn't wired into precommit first, and doesn't work for projects
that require specific signatures, etc. It's meant to show how this can
be used. The next step is to make a custom task type and configure it
based on the project extension from the pugin and make some minor
adjustments to some build scripts as we can't  bee 100% compatible with
that at least due to how additional signatures are passed.

Notes:
- there's no `--target` for the CLI version so we have to pass in
specific bundled signature names
- the cli task already wires to `runtimeJavaHome`
- no equivalent for `failOnUnsupportedJava = false` but doesn't seem to
be a problem. Tested with Java 8 to 11
- there's no way to pass additional signatures as URL, these will have
to be on the file system, and can't be resources on the cp unless we
rely on how forbiddenapis is implemented and mimic them as boundled
signatures.
- the average of 3 runs is 4% slower using the CLI for :server.
( `./gradlew clean :server:forbiddenApis` vs `./gradlew clean
:server:forbiddenApisCli`)
- up-to-date checks don't work on the cli task yet, that will happen
with the custom task.

See also: elastic#31715
@alpar-t alpar-t added the :Delivery/Build Build or test infrastructure label Jul 16, 2018
@elasticmachine
Copy link
Collaborator

Pinging @elastic/es-core-infra

Copy link
Member

@nik9000 nik9000 left a comment

Choose a reason for hiding this comment

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

This seems like a good start for forking this. I left some minor things.

forbiddenApisCliJar 'de.thetaphi:forbiddenapis:2.5'
}
Task forbiddenApisCli = project.tasks.create('forbiddenApisCli')
project.ext.getForbiddenSignaturesFile = { name -> project.getForbiddenSignaturesFile(name) }
Copy link
Member

Choose a reason for hiding this comment

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

Do we need this one? It looks circular.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It's so we can call getForbiddenSignaturesFile(name) from a build script instead of import ... ; PrecommitTasks.getForbiddenSignaturesFile(project, name)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I'll remove it for now, and add it back once it's actually used.

return forbiddenApisCli
}

private static File getForbiddenSignaturesFile(project, String name) {
Copy link
Member

Choose a reason for hiding this comment

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

Could you add a type to the project parameter?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I haven't found a good way to fight IDEA on this ...
The refactoring don't add a type. Will change it.

Copy link
Member

@nik9000 nik9000 left a comment

Choose a reason for hiding this comment

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

LGTM

Copy link
Member

@rjernst rjernst left a comment

Choose a reason for hiding this comment

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

This looks good. The only critical thing I see is how the resource files are loaded.

executable = "${project.runtimeJavaHome}/bin/java"
[
'jdk-unsafe-1.8', 'jdk-deprecated-1.8', 'jdk-non-portable', 'jdk-system-out'
].forEach { args "-b", it }
Copy link
Member

Choose a reason for hiding this comment

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

I think this would be easier to read not using a foreach. Just call args directly with each argument.

[
getForbiddenSignaturesFile(project, 'jdk-signatures'),
getForbiddenSignaturesFile(project, 'es-all-signatures')
].forEach { args "-f", it }
Copy link
Member

Choose a reason for hiding this comment

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

Same here, the foreach just makes this harder to read.

}

private static File getForbiddenSignaturesFile(Project project, String name) {
return project.rootProject.file('buildSrc/src/main/resources/forbidden/' + name + '.txt')
Copy link
Member

Choose a reason for hiding this comment

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

We can't assume this is accessible, since build-tools is used by external plugin developers. We need to load this from resources and copy to a local file.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I wasn't aware we publish group: 'org.elasticsearch.gradle', name: 'build-tools', version: '6.3.1' and encourage others to use it. Is this fully documented or more like plugin authors picked up on it ? I don't think we have documentation on any of the build plugins. I think I broke this assumption recently with the naming conventions check, I'll take a look and see if we can add some tests for this.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Naming conventions check is fine, it looks up the source jar of the relevant class so works as long as the jar is on the file system, the class doesn't have to be. I'll still add a test for this.

Copy link
Member

Choose a reason for hiding this comment

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

It's not "documented", but we have encouraged plugin authors to use it since we switched to gradle in 5.0. We have long needed a permanent home for plugin author documentation, but we probably need a broader reorg of the docs to enable that, as there are a few parts for plugin authors to consume eg how to build, how to test, core apis and services available, how to publish, etc.

alpar-t added 3 commits July 18, 2018 17:25
Fails with:
```
ERROR: IO problem while reading files with API signatures: java.io.FileNotFoundException: /home/alpar/work/elastic/elasticsearch/buildSrc/src/testKit/forbidden-apis/buildSrc/src/main/resources/forbidden/jdk-signatures.txt (No such file or directory)
```
because signature definitiions are accessed on the FS directly.
@alpar-t
Copy link
Contributor Author

alpar-t commented Jul 20, 2018

Depends on #32201 for completion.

@alpar-t
Copy link
Contributor Author

alpar-t commented Aug 10, 2018

@rjernst This now uses the buildResources task to pass in the files.

Copy link
Member

@rjernst rjernst left a comment

Choose a reason for hiding this comment

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

LGTM aside from the naming I noted in #32201

@alpar-t
Copy link
Contributor Author

alpar-t commented Aug 13, 2018

I changed the name tocopy

@alpar-t alpar-t merged commit 02f2fad into elastic:master Aug 13, 2018
@alpar-t alpar-t deleted the fix/forbidden-APIs-checks-jvm-31715 branch August 13, 2018 05:52
jasontedor added a commit to jasontedor/elasticsearch that referenced this pull request Aug 13, 2018
…listeners

* elastic/master: (58 commits)
  [ML] Partition-wise maximum scores (elastic#32748)
  [DOCS] XContentBuilder#bytes method removed, using BytesReference.bytes(docBuilder) (elastic#32771)
  HLRC: migration get assistance API (elastic#32744)
  Add a task to run forbiddenapis using cli (elastic#32076)
  [Kerberos] Add debug log statement for exceptions (elastic#32663)
  Make x-pack core pull transport-nio (elastic#32757)
  Painless: Clean Up Whitelist Names (elastic#32791)
  Cat apis: Fix index creation time to use strict date format (elastic#32510)
  Clear Job#finished_time when it is opened (elastic#32605) (elastic#32755)
  Test: Only sniff host metadata for node_selectors (elastic#32750)
  Update scripted metric docs to use `state` variable (elastic#32695)
  Painless: Clean up PainlessCast (elastic#32754)
  [TEST] Certificate NONE not allowed in FIPS JVM (elastic#32753)
  [ML] Refactor ProcessCtrl into Autodetect and Normalizer builders (elastic#32720)
  Access build tools resources (elastic#32201)
  Tests: Disable rolling upgrade tests with system key on fips JVM (elastic#32775)
  HLRC: Ban LoggingDeprecationHandler (elastic#32756)
  Fix test reproducability in AbstractBuilderTestCase setup (elastic#32403)
  Only require java<version>_home env var if needed
  Tests: Muted ScriptDocValuesDatesTests.testJodaTimeBwc
  ...
alpar-t added a commit that referenced this pull request Aug 22, 2018
* Add a task to run forbiddenapis using cli

Add a task that offers an equivalent check to the forbidden APIs plugin,
but runs it using the forbiddenAPIs CLI instead.

This isn't wired into precommit first, and doesn't work for projects
that require specific signatures, etc. It's meant to show how this can
be used. The next step is to make a custom task type and configure it
based on the project extension from the pugin and make some minor
adjustments to some build scripts as we can't  bee 100% compatible with
that at least due to how additional signatures are passed.

Notes:
- there's no `--target` for the CLI version so we have to pass in
specific bundled signature names
- the cli task already wires to `runtimeJavaHome`
- no equivalent for `failOnUnsupportedJava = false` but doesn't seem to
be a problem. Tested with Java 8 to 11
- there's no way to pass additional signatures as URL, these will have
to be on the file system, and can't be resources on the cp unless we
rely on how forbiddenapis is implemented and mimic them as boundled
signatures.
- the average of 3 runs is 4% slower using the CLI for :server.
( `./gradlew clean :server:forbiddenApis` vs `./gradlew clean
:server:forbiddenApisCli`)
- up-to-date checks don't work on the cli task yet, that will happen
with the custom task.

See also: #31715
@mark-vieira mark-vieira added the Team:Delivery Meta label for Delivery team label Nov 11, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
:Delivery/Build Build or test infrastructure Team:Delivery Meta label for Delivery team v6.5.0 v7.0.0-beta1
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants