Thanks Zhuoyu for your driving. Currently, Frequent timeout because we merge build and test into one stage. Github testing timeout 1H for one stage. So there are lots of timeout now.
But if we can optimize testing time is better. Thanks for your idea. Maybe we can list all tests to show how to separate them. Best, Jingsong On Sun, Aug 20, 2023 at 7:39 PM 陈卓宇 <[email protected]> wrote: > > Subject: Optimizing UTCase and ITCase Flink Action Execution Time > > Hi devs, > > I've observed that the average execution time for our UTCase and ITCase > Flink Action has approached the critical threshold of 1 hour. Upon > reviewing, I found that this action corresponds to > `.github/workflows/utitcase-flink.yml`. The core execution command is: > ``` > mvn clean install -pl 'org.apache.paimon:paimon-flink-common' > -Duser.timezone=$jvm_timezone > ``` > This command runs UT and IT tests for `paimon-flink-common`. > > To optimize this, I've considered a few strategies: > > 1. **Splitting IT Tests by Functionality or Module**: By segmenting the IT > tests, we can define separate steps or jobs for each module within GitHub > Actions. > > 2. **Utilizing Maven Profiles**: We can define different Maven Profiles in > the `pom.xml`, where each profile corresponds to a set of integration > tests. Subsequently, in GitHub Actions, we can define a distinct step or > job for each profile. For instance, in `pom.xml`: > ```xml > <profiles> > <profile> > <id>ITGroup1</id> > <build> > <plugins> > <plugin> > <groupId>org.apache.maven.plugins</groupId> > <artifactId>maven-failsafe-plugin</artifactId> > <configuration> > <includes> > <include>**/ITGroup1*.java</include> > </includes> > </configuration> > </plugin> > </plugins> > </build> > </profile> > <!-- ... other profiles for other IT groups ... --> > </profiles> > ``` > And then, in the GitHub Actions configuration, we can define a step for > each profile: > ```yaml > - name: Run IT Group 1 > run: mvn -PITGroup1 verify > ``` > > I'd love to hear if anyone has other ideas or better approaches to this > issue. Let's collaborate and discuss the best way forward. > > Best regards, > ZhuoyuChen
