There are many ways that you can help the SkyWalking community.
dev@skywalking.apache.org. Mail to dev-subscribe@skywalking.apache.org, follow the reply to subscribe the mail list.All the following channels are open to the community, you could choose the way you like.
dev-subscribe@skywalking.apache.org, follow the reply to subscribe the mail list.The PMC will assess the contributions of every contributor, including, but not limited to, code contributions, and follow the Apache guides to promote, vote and invite new committer and PMC member. Read Become official Apache SkyWalking Committer to get details.
For developers, first step, read Compiling Guide. It teaches developer how to build the project in local and set up the environment.
After setting up the environment and writing your codes, in order to make it more easily accepted by SkyWalking project, you‘ll need to run the tests locally to verify that your codes don’t break any existed features, and write some unit test (UT) codes to verify that the new codes work well, preventing them being broke by future contributors. If the new codes involve other components or libraries, you're also supposed to write integration tests (IT).
SkyWalking leverages plugin maven-surefire-plugin to run the UTs while using maven-failsafe-plugin to run the ITs, maven-surefire-plugin will exclude ITs (whose class name starts with IT) and leave them for maven-failsafe-plugin to run, which is bound to the verify goal, CI-with-IT profile. Therefore, to run the UTs, try ./mvnw clean test, this will only run the UTs, not including ITs.
If you want to run the ITs please activate the CI-with-IT profile as well as the the profiles of the modules whose ITs you want to run. e.g. if you want to run the ITs in oap-server, try ./mvnw -Pbackend,CI-with-IT clean verify, and if you'd like to run all the ITs, simply run ./mvnw -Pall,CI-with-IT clean verify.
Please be advised that if you're writing integration tests, name it with the pattern IT* to make them only run in CI-with-IT profile.
Since version 6.3.0, we have introduced more automatic tests to perform software quality assurance, E2E is one of the most important parts.
End-to-end testing is a methodology used to test whether the flow of an application is performing as designed from start to finish. The purpose of carrying out end-to-end tests is to identify system dependencies and to ensure that the right information is passed between various system components and systems.
The e2e tests involves the OAP server, Web App, and the instrumented services, all of them run in a designed Docker container, connecting to each other; in addition, there is a test controller running outside of the container that sends requests to the instrumented service, and then verifies the corresponding results after those requests, by GraphQL API of the SkyWalking Web App.
Run the command ./mvnw -f test/e2e/pom.xml clean verify under the root directory to get an intuition on how they work together(note that it may take a long time).
The e2e test is an individual project under the SkyWalking root directory and the IDEA cannot recognize it by default, right click on the file test/e2e/pom.xml and click Add as Maven Project, things should be ready now.
Our goal of E2E tests is to test the SkyWalking project in a whole, including the OAP server, Web App, and even the frontend UI(not now), in single node mode as well as cluster mode, therefore the first step is to determine what case we are going to verify and orchestrate the components.
In order to make it more easily to orchestrate, we're using a Docker e2e-container that can run OAP server in both standalone and cluster mode, it can also run the given instrumented services. Refer to the repository for more details;
Basically you will need:
/rc.d/ in e2e-container and it gets run when the container starts up;We've given a simple example that verifies SkyWalking should work as expected in cluster mode, refer to the codes for detail.
To put it simple, test controllers are basically tests that can be bound to the Maven integration-test/verify phase. They send designed requests to the instrumented service, and expect to get corresponding traces/metrics/metadata from the SkyWalking webapp GraphQL API.
SkyWalking project supports many ways to extend existing features. If you are interesting in these ways, read the following guides.
config/official_analysis.oal. You could change it and reboot the OAP server. Read Observability Analysis Language Introduction if you need to learn about OAL script.Our UI is constituted by static pages and web container.
apm-webapp module. This is a just an easy zuul proxy to host static resources and send GraphQL query requests to backend.This section is only applicable to the dependencies of the backend module
Being one of the Top Level Projects of The Apache Software Foundation (ASF), SkyWalking is supposed to follow the ASF 3RD PARTY LICENSE POLICY, so if you‘re adding new dependencies to the project, you’re responsible to check the newly-added dependencies won‘t break the policy, and add their LICENSE’s and NOTICES's to the project.
We have a simple script to help you make sure that you didn't miss any newly-added dependency:
dist.apm-dist/release-docs/{LICENSE,NOTICE} file.tools/dependencies/known-oap-backend-dependencies.txt file (alphabetical order), the next run of check-LICENSE.sh should pass.Apache Release Guide introduces to the committer team about doing official Apache version release, to avoid breaking any Apache rule. Apache license allows everyone to redistribute if you keep our licenses and NOTICE in your redistribution.