Reducing sponsered travis-ci build time

[raveit65]

As everybody know MATE desktop is sponsored as open-source project by travis-ci company. That means we get 25.000 credits from them when someone from the team ask for it. For this reason i disabled building with Archlinux and Ubuntu docker image a while ago. When credits are low (~1000) we have to ask for more with a simple email. Something like this:

Dear Travis support,
i want to noticed you that sponsored credits for mate-desktop are running out again. Can you please update oss credits?
Thank you so much for your sponsoring.
Best regards

...or in better English :) Edit: Everybody from the team can ask for more credits. Usually after 1 or 2 hours we got again 25.000 credits.

With a travis account you will see this page with our current credits. https://app.travis-ci.com/organizations/mate-desktop/plan In October i ask 3 times for new credits (2023-10-02, 2023-10-10 and 2023-10-19), which is a lot.

Building with debian docker image is useful for seeing ccpcheck warnings and we use a higher compiler warnings level. Fedora build is needed for doing releases and displaying github pages for ccpcheck results. We can change that if someone thinks it's better to build on Ubuntu or Archlinux, but this requires work to change configs for every repository. How can we reduce build time? Because i don't want to write every 9 days a mail to travis and we should handle sponsored build time with respect.

Currently we build every commit or every force push in a pull request 2 times for fedora and debian. One time in PR feature branch, and one time PR feature branch against master. I am thinking that isn't really needed and building the PR only against master branch is sufficient. This step would reduce our build-time by 50% @mate-desktop/core-team What do you think? @yetist Is this possible and what change is needed in ci config?

[zhuyaliang]

I am thinking that isn't really needed and building only the PR against master branch is sufficient.

Agree to this suggestion, which requires the assistance of @yetist to complete

[lukefromdc]

The fact that every push or force-push to any PR triggers new builds burns a ton of credits. The fact that presumably nobody pushes code without building it first should mean we get one successful build before a push anyway.

Shutting that off might mean having to revisit a few more PR's but would save a lot of credits. Maybe a way to manually trigger builds when a PR is deemed ready for a test?

[raveit65]

Shutting that off might mean having to revisit a few more PR's but would save a lot of credits. Maybe a way to manually trigger builds when a PR is deemed ready for a test?

Good idea. At travis site it is possible to trigger a manual build from every commit.

Another way is to push first only to the feature branch without opening a PR, until the PR is ready for review. I this case every push will trigger only one build and author can take a look at travis for the build logs.

But i don't wanna make it uncomfortable. In general the task of CI is to help developers and a developer shouldn't think about credits.

Btw. we are sponsored until July 31, 2014 ( see screenshot). I hope travis will only review their sponsoring.

[raveit65]

I found the setting for the type of builds. Example libmateweather: When disabling build pushed pull requests setting a new PR looks like this. I think this is OK because we get a warning when a rebase from master isn't possible during merging. If new commits are in master we only need to rebase the branch to see if they are conflicts. If all agree i will change settings of all repositories.

[zhuyaliang]

@raveit65 agree with ，Thank you

[lukefromdc]

I agree too

[yetist]

I agree too.

And the other way, to update the .travis.yml like this:

branches:                                                                        
  only:                                                                          
  - master                                                                       
...
script:
   - 'if [ "$TRAVIS_PULL_REQUEST" != "false" ]; then bash ./docker-build --name ${DISTRO} --verbose --config .build.yml --build scripts; fi'

[yetist]

The Travis documents about Double builds’ on pull requests is here: https://docs.travis-ci.com/user/pull-requests/#double-builds-on-pull-requests

[raveit65]

'if [ "$TRAVIS_PULL_REQUEST" != "false" ]; then bash ./docker-build --name ${DISTRO} --verbose --config .build.yml --build scripts; fi'

With this suggestion behavior is same as before. We have double build on PRs (Build pushed branches and Build pushed pull requests. See https://github.com/mate-desktop/libmatekbd/pull/87 And deployment failed with this suggestion. https://app.travis-ci.com/github/mate-desktop/libmatekbd/jobs/612020507#L507

[raveit65]

When disabling Build pushed pull requests we have only one build, but we lost displaying ccpcheck results at gh-pages. https://github.com/mate-desktop/libmatekbd/pull/88 I am thinking this is OK because we see ccpcheck warnings in debian build, and Build pushed pull requests can be explicific enabled if someone need to see them at gh-pages, for example a developer try to fix those warnings. IHMO, nobody from current team use this feature really.

PS: ....i am really happy if anyone use CI build log for reviews, otherwise using CI is complete overload only to see that a build finished ;-)