Another downside of merging build and test is: There are two many logs when testing fails. (Logs of building is too large)
Best, Jingsong On Mon, Aug 21, 2023 at 11:18 AM yu zelin <[email protected]> wrote: > > I agree with @Liugddx. I think the Flink CDC related codes can be a separated > test. > > Best, > Zelin Yu > > > 2023年8月21日 10:09，Guangdong Liu <[email protected]> 写道： > > > > We can disassemble the test case, it is estimated that it will be faster. > > > > -- > > > > Best Regards > > > > ------------ > > > > Liugddx > > [email protected] > > > > > > yu zelin <[email protected]> 于2023年8月21日周一 10:07写道： > > > >> Hi, all, > >> > >> Currently, we can set `timeout-minutes: 60` to longer time as a temporary > >> solution. > >> > >> Best, > >> Zelin Yu > >> > >> On Mon, Aug 21, 2023 at 9:49 AM Jingsong Li <[email protected]> > >> wrote: > >> > >>> 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 > >>> > >> >
