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

Windows smoke tests for Jetty, Tomcat, GlassFish #87

Merged
merged 9 commits into from
Jan 22, 2021

Conversation

agoallikmaa
Copy link
Contributor

Adds tasks and Dockerfiles to build Windows Docker images for:

  • OpenTelemetry collector
  • Fake backend (required duplicating it from OpenTelemetry repository)
  • Jetty
  • Tomcat
  • GlassFish (Payara)

Implements an alternative way of test container management that works with Windows images (by using docker-java directly) as Testcontainers does not support Windows images. Platform and type (proprietary or not) are now also specified for images used in smoke tests to determine which images can be tested with on the current system.

Running Windows smoke tests also added to CI workflow, where for now, the Windows images are built locally before running tests.

Copy link
Contributor

@vovencij vovencij left a comment

Choose a reason for hiding this comment

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

What would be the steps if one would like to push windows tests upstream?

@iNikem
Copy link
Contributor

iNikem commented Jan 19, 2021

Quick question: why fake-backend on windows cannot be upstreamed to Otel?

matrix/build.gradle Show resolved Hide resolved
matrix/build.gradle Show resolved Hide resolved
matrix/build.gradle Show resolved Hide resolved
matrix/src/jetty-split.windows.dockerfile Show resolved Hide resolved
private static final Logger logger = LoggerFactory.getLogger(WindowsTestContainerManager.class);

private static final String NPIPE_URI = "npipe:////./pipe/docker_engine";
private static final String COLLECTOR_CONFIG_FILE_PATH = "/collector-config.yml";
Copy link
Contributor

Choose a reason for hiding this comment

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

Why do we need this to differ from AbstractTestContainerManager#COLLECTOR_CONFIG_RESOURCE?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The difference in values is not actually necessary, but I think separate fields still make sense, because they are used in different places - the RESOURCE one refers to the filename in the test code classpath, and the PATH refers to the filename used in container filesystem.

Copy link
Contributor

Choose a reason for hiding this comment

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

And that PATH is only relevant for Windows-based images?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The path only needs to be consistent across the copy to container operation and command used to launch the collector, which are both done in the same class. Therefore it is an internal implementation details of the container manager and there is no need to expose it to any other class.

}
}

public static class Http extends TargetWaitStrategy {
Copy link
Contributor

Choose a reason for hiding this comment

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

Is this used?

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 the logic for waiting behind http endpoint was internally already implemented as it was used for fake backend, it made sense to keep the list of wait strategies in sync with the capabilities that are already implemented anyway.

@iNikem
Copy link
Contributor

iNikem commented Jan 19, 2021

Will other app servers follow to Windows as well?

@vovencij
Copy link
Contributor

Quick question: why fake-backend on windows cannot be upstreamed to Otel?

I think we have to look at the wider picture here - upstreaming just fake-backend is not very useful without at least one test that would use it. But for that we also would need the windows-dockerized collector. These could be follow up steps within the effort of open-sourcing the test matrix.

@agoallikmaa
Copy link
Contributor Author

Quick question: why fake-backend on windows cannot be upstreamed to Otel?

It could, but then that would be a blocker for this, and I'm not sure if upstreaming the backend alone would make sense until some Windows tests are upstreamed as well.

What would be the steps if one would like to push windows tests upstream?

Pretty much just adapt all the additional logic in both matrix and smoke-tests upstream.

@iNikem
Copy link
Contributor

iNikem commented Jan 20, 2021

Rebase this PR please

@agoallikmaa
Copy link
Contributor Author

Rebase this PR please

Done.

@agoallikmaa
Copy link
Contributor Author

Will other app servers follow to Windows as well?

I do not see any reason why not, but they are not in the scope of my current task.

@vovencij vovencij mentioned this pull request Jan 22, 2021
@iNikem iNikem merged commit 175a0dd into signalfx:main Jan 22, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants