chore: remove automation to pull gherkin specs

[mdelapenya]

What does this PR do?

This PR removes the existing automation to pull the gherkin specs from the APM repository, as following updates will come in the way of a PR to this repo.

Checklist

- [ ] My code follows the style guidelines of this project

• I have rebased my changes on top of the latest master branch

- [ ] I have made corresponding changes to the documentation
- [ ] I have added tests that prove my fix is effective or that my feature works
- [ ] New and existing unit tests pass locally with my changes

- [ ] I have updated CHANGELOG.asciidoc
- [ ] I have updated supported-technologies.asciidoc
- [ ] Added an API method or config option? Document in which version this will be introduced
- [ ] Added an instrumentation plugin? How did you make sure that old, non-supported versions are not instrumented by accident?

Related issues

• Relates Jenkins pipeline for sending PRs to agents when changing the BDD specs apm#231

[mdelapenya]

BTW, I found this flakiness in a CI build: is it happening at any other build?

• https://apm-ci.elastic.co/job/apm-agent-java/job/apm-agent-java-mbp/job/PR-1105/1/testReport/ (2 unit tests broken)
• https://apm-ci.elastic.co/job/apm-agent-java/job/apm-agent-java-mbp/job/PR-1105/2/testReport/ (1 unit test broken after replaying same build)
• https://apm-ci.elastic.co/blue/organizations/jenkins/apm-agent-java%2Fapm-agent-java-mbp/detail/PR-1105/3/tests (1 different unit broken test replaying same build)

[codecov-io]

Codecov Report

Merging #1105 into master will increase coverage by 4.46%.
The diff coverage is n/a.

@@             Coverage Diff              @@
##             master    #1105      +/-   ##
============================================
+ Coverage     59.96%   64.43%   +4.46%     
- Complexity       87     2763    +2676     
============================================
  Files           327      282      -45     
  Lines         14769    13369    -1400     
  Branches       2059     1839     -220     
============================================
- Hits           8856     8614     -242     
+ Misses         5316     4183    -1133     
+ Partials        597      572      -25     

Impacted Files	Coverage Δ	Complexity Δ
...pentracing/impl/ApmSpanBuilderInstrumentation.java
...tracing/impl/OpenTracingBridgeInstrumentation.java
...t/kafka/helper/ConsumerRecordsIteratorWrapper.java
...ntracing/impl/ElasticApmTracerInstrumentation.java
...stic/apm/agent/kafka/BaseKafkaInstrumentation.java
...t/kafka/helper/ConsumerRecordsIterableWrapper.java
.../apm/agent/kafka/KafkaProducerInstrumentation.java
.../apm/agent/kafka/KafkaConsumerInstrumentation.java
.../agent/hibernate/search/HibernateSearchHelper.java
...astic/apm/opentracing/TraceContextSpanContext.java
... and 41 more

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update f62625a...b7002cb. Read the comment docs.

[felixbarny]

Thanks for reporting the flaky tests. I've created an issue template, a flaky-tests tag and two issues to start the fight against the flakiness ✊

It would be great to have statistics over what the flakiest tests are so we can fight the overall flakiness more effectively.

[SylvainJuge]

I'm not really sure about completely removing those scripts, for example we sometimes have to work on specs that are in-progress and thus not yet merged on master.

In that case, does it mean that we have to use a manual copy of the files from apm repository in order to be able to work on a different version ? Or is there a way to trigger the "automatically create PR job" to run on another branch of apm and open PR with a different target branch ?

That's probably not a big deal, and we can use a manual copy, but given agents tend to have different implementation timelines that might happen quite often in practice.

[felixbarny]

I think it's fine having to manually copy a spec if it's still a (draft) PR. The norm should be that only approved spec changes are used by the agents.

Personally, by the time I look up which parameters I have to set in order to specify the PR branch, I can just copy/paste from the PR 😅

[cachedout]

@felixbarny Regarding flaky tests, we have some ideas about how to produce reports that we'll be working on and will be available to all Observability teams. In the meantime, I wonder if you might be interested in exploring using the capability of Maven Surefire to re-run tests X number of times if they fail. Here is a commit message in the maven surefire repo describing this capability:

apache/maven-surefire@fefaae7

[SylvainJuge]

Ok, let's go with a manual merge then, I agree that seldom used scripts take dust faster than expected, especially if there is a manual alternative.

Regarding flaky tests, as far as I know this surefire option does not work anymore with Junit5, mostly because those tests are created by junit directly instead of being instantiated by surefire.

I haven't found a really decent alternative that works with Junit5, also if we have a common way to track flaky tests, we could also apply it to other agent builds and integration tests.

[cachedout]

I haven't found a really decent alternative that works with Junit5, also if we have a common way to track flaky tests, we could also apply it to other agent builds and integration tests.

OK, sounds good. We'll keep you updated on our progress with flaky test reporting.