Optimize drone.star file

[amrita-shrestha]

Describe the bug

There are several areas where optimization can be applied to the drone. While I've highlighted some points, please continue to explore additional areas where optimization is needed during the process.

• manage pipeline time to minimize overall time to finish build Optimize drone.star file #8794 (comment)
  

IMO opinion we need to split shareng tests in 2 parts as you can see it crossing 15 min and still there are ongoing PR which adds tests on shreng
- one way to split is separate tests of sharing space using root endpoint in separate folder
@saw-jan any idea about this or we don't need to split ❓

• pipeline should displayed according to its trigger time [tests-only][full-ci] updated drone file to display pipeline in order by trigger #8823
  

• chat notification only trigger on failure. trigger chat notification both for passed and failures on nightly [tests-only][full-ci] notify chat also on nightly success #8832

• check stable and master branch drone.star file (make it similar as much as possible)

  • [tests-only][full-ci] updated drone file to display pipeline in order by trigger #8823
  • [tests-only][full-ci] notify chat also on nightly success #8832
  • [tests-only][full-ci] backport send nightly notification to builds channel #8874

• Check naming [tests-only][full-ci]rename e2e test suite #8867
  

• send chat notifications of normal build to infinitescale and nightly to builds channel [tests-only][full-ci]send nightly notification to builds channel #8866

• do not run web smoke test pipelines in nightly and full-ci PRs [tests-only] [full-ci] remove web smoke tests from nightly and full ci #8929

• check if web stable has runner or not. If possible backport runner implementation PR on web stable [tests-only][full-ci] backport e2e runner implementation #8934

• make return type similar to maintain standard (some returns dict data type where some returns list ) [tests-only][full-ci] make function's return type in drone file similar #9039

• split apiSharingNg test suite to tow or more parts [tests-only][full-ci] divide shareNg test suite into multiple parts #9158

[individual-it]

After discussing with @ScharfViktor I've added an other todo item to change the destination of the notifications

[saw-jan]

After discussing with @ScharfViktor I've added an other todo item to change the destination of the notifications

Dev team might miss the ocis builds status so should we move to builds channel?

[individual-it]

This is to reduce the noise. What about putting the normal builds into the ocis channel and only the nightly into builds?

[saw-jan]

This is to reduce the noise. What about putting the normal builds into the ocis channel and only the nightly into builds?

sounds good to me

[PrajwolAmatya]

• manage pipeline time to minimize overall time to finish build

Current CI takes less than 30 minutes to complete. Likewise, each pipeline completes within 15 minutes or less. Of all the localApiTests, localApiTests-apiSpacesShares-ocis takes more time to complete, roughly around 15 min, as it contains the most number of scenarios, 404 scenarios and 4421 steps. The time seems to be relevant, but we should keep monitoring the time of completion of every pipelines and overall time of completion of CI.

[saw-jan]

Let's close the issue as done.

CC @amrita-shrestha

[saw-jan]

• make return type similar to maintain standard (some returns dict data type where some returns list)

Let's make all functions that return step or pipeline return list ([{...}])

[saw-jan]

IMO opinion we need to split shareng tests in 2 parts as you can see it crossing 15 min and still there are ongoing PR which adds tests on shreng

• one way to split is separate tests of sharing space using root endpoint in separate folder
  @saw-jan any idea about this or we don't need to split ❓

better to split the apiSharingNg into two or more suites (features grouped accordingly)

[saw-jan]

@PrajwolAmatya Can we close this one?

[PrajwolAmatya]

@PrajwolAmatya Can we close this one?

With the changes, the CI completes inside 30 mins. But, regular inspection would be needed for the CI run time. As all the tasks in this issue has been covered, we can close this issue.