Skip to content

Conversation

@drodriguezhdez
Copy link
Contributor

Added CI/Git information to test spans for the following CI providers:

  • TravisCI
  • CircleCI
  • Azure Pipelines
  • GitHub Actions
  • Buildkite
  • BitBucket
  • AppVeyor

@drodriguezhdez drodriguezhdez added the tag: no release notes Changes to exclude from release notes label Oct 1, 2020
@drodriguezhdez drodriguezhdez requested a review from a team as a code owner October 1, 2020 15:33
@drodriguezhdez drodriguezhdez self-assigned this Oct 1, 2020
@drodriguezhdez drodriguezhdez force-pushed the drodriguezhdez/ci_providers branch from 5955fce to d45d49d Compare October 2, 2020 07:08
setJenkinsData();
} else if (System.getenv(GITLAB) != null) {
setGitLabData();
} else if (System.getenv(TRAVIS) != null) {
Copy link
Contributor

Choose a reason for hiding this comment

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

Do you want a hierarchy here instead?

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 think it's fine to have it like this. A hierarchy for CI/Git decorators is too specific for the "CiApp" use case, and it will not be reusable for any other case. I'd not create a lot of decorators only for this case, IMHO.

Copy link
Contributor

Choose a reason for hiding this comment

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

I think the code would be easier to read if things were pulled apart a bit, so that you have one abstract CiInformation class that has all the methods that you need to implement, i.e. getProviderName(), getPipelineId et.c., and then have a specific subclass for each provider like gitlab, travis, et.c. As it's written right now, I can't really see if all the setter methods actually set all the fields they should.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Refactored into different CIProviderInfo implementations.

import org.junit.contrib.java.lang.system.EnvironmentVariables
import spock.lang.Shared

import static datadog.trace.bootstrap.instrumentation.decorator.TestDecorator.APPVEYOR
Copy link
Contributor

Choose a reason for hiding this comment

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

Could this be a wildcard import?

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 think we could do it, but setting a smaller number in the Imports configuration in the IDE.
Now, following the CONTRIBUTING.md, is set to 9999.

* Editor > Code Style > Java/Groovy > Imports
  * Class count to use import with '*': `9999` (some number sufficiently large that is unlikely to matter)
  * Names count to use static import with '*': `9999`

Copy link
Contributor Author

Choose a reason for hiding this comment

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

As TestDecoratorTest has been refactored, this comment has been resolved.

@drodriguezhdez drodriguezhdez merged commit bb193a8 into master Oct 5, 2020
@drodriguezhdez drodriguezhdez deleted the drodriguezhdez/ci_providers branch October 5, 2020 12:18
@github-actions github-actions bot added this to the 0.65.0 milestone Oct 5, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

tag: no release notes Changes to exclude from release notes

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants