search

epics-base / ci-scripts

Continuous Integration Scripts for EPICS Modules
Other
8 stars 18 forks source link

Prevent builds on Appveyor when only travis files modified? #34

Closed anjohnson closed 4 years ago

anjohnson commented 4 years ago

Is it possible to add something like

skip_commits:
  files:
    - .ci/travis/*

to the Base .appveyor.yml files and any equivalents in this module to prevent Appveyor from wasting build time unnecessarily? I've been waiting all day to push a merge-up of the latest Base-3.15 changes into 7.0 (which went well BTW, I did it to check that it would) as I didn't want to preempt your 7.0 build on Appveyor, but it hasn't started building either of your use-ci-scripts merges to Base yet.

ralphlange commented 4 years ago

It is possible to add such configuration, but it wouldn't work, as .ci is a git submodule and the files you intend to ignore are not part of the "user" (in this case Base) repository. The only files that can be ignored this way are the .travis.yml and .appveyor.yml configuration files on the 'other' service.

ralphlange commented 4 years ago

And please preempt or cancel builds as you see fit. Those builds can be re-run later if they are needed.

I am always using my personal AppVeyor account to do the builds while I am developing. The EPICS Base CI is rightfully doing a build after a merge commit that introduced a new submodule and changed/deleted half a dozen files.

mdavidsaver commented 4 years ago

@anjohnson The Rolling builds logic wouldn't cancel a 7.0 build when you push to another branch. There is no reason to wait before pushing 3.15 changes.

“Rolling builds” are great for very active OSS projects with lengthy queue. Whenever you do a new commit to the same branch OR pull request all current queued/running builds for that branch or PR are cancelled and the new one is queued.

ralphlange commented 4 years ago

He was waiting to push a 7.0 commit, though, which would have cancelled my 7.0 commit that was standing in the queue. Creating a PR for that 7.0 commit would have put it in the build queue without cancelling.

anjohnson commented 4 years ago

Okay. We should ignore changes to the .travis.yml file in the Base .appveyor.yml file at some point though. The other way around doesn't matter quite as much since our Travis builds don't take many hours to complete, and I'm not sure if the Travis config has a similar setting anyway.