ocis
ocis copied to clipboard
Optimize drone.star file
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.
- [x] manage pipeline time to minimize overall time to finish build https://github.com/owncloud/ocis/issues/8794#issuecomment-2061011954
- [x] pipeline should displayed according to its trigger time https://github.com/owncloud/ocis/pull/8823
-
[x] chat notification only trigger on failure. trigger chat notification both for passed and failures on nightly https://github.com/owncloud/ocis/pull/8832
-
[x] check
stable and master
branch drone.star file (make it similar as much as possible)- https://github.com/owncloud/ocis/pull/8823
- https://github.com/owncloud/ocis/pull/8832
- https://github.com/owncloud/ocis/pull/8874
-
[x] Check naming https://github.com/owncloud/ocis/pull/8867
-
[x] send chat notifications of normal build to
infinitescale
and nightly tobuilds
channel https://github.com/owncloud/ocis/pull/8866 -
[x] do not run web smoke test pipelines in nightly and full-ci PRs https://github.com/owncloud/ocis/pull/8929
-
[ ] check if web stable has runner or not. If possible backport runner implementation PR on web stable https://github.com/owncloud/ocis/pull/8934
-
[x] make return type similar to maintain standard (some returns
dict
data type where some returnslist
) https://github.com/owncloud/ocis/pull/9039
After discussing with @ScharfViktor I've added an other todo item to change the destination of the notifications
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?
This is to reduce the noise. What about putting the normal builds into the ocis channel and only the nightly into builds
?
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
- [ ] 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.
Let's close the issue as done.
CC @amrita-shrestha
- [ ] 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 ([{...}]
)
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)
@PrajwolAmatya Can we close this one?
@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.