-1

We are using GitHub and CircleCI. I know that pull request mergeability can be made to be dependent on the most recent commit, using status checks. Is there any way to make it depend on whether or not a build is running? How?

  • 2
    Why would you want to do that? – D Drmmr Apr 10 '19 at 19:16
  • Does Circle CI supports comcurrent builds for the same reposistory? Could not just disable comcurrent builds? – Laiv Apr 10 '19 at 19:39
  • @Laiv merely preventing concurrent builds is not sufficient; we want to prevent new commits to the branch while the build is running. – Elliott Shugerman Apr 10 '19 at 20:02
  • @DDrmmr we want to push a commit as part of the build process. Disabling merges while a build is running is the safest and simplest way to ensure that the push does not fail. – Elliott Shugerman Apr 10 '19 at 20:03
  • @Laiv No, that's not why. See my response to DDrmmr. – Elliott Shugerman Apr 10 '19 at 20:26
2

If you want to push a commit as part of the build process, my recommendation would be to do it in a separate branch. Maybe call it release or builds or something. Then just limiting to one concurrent build would ensure no conflicts. Alternately, if what you are pushing is a version number, you could consider using tags instead. If it's some other kind of artifact, you might consider using an artifact repository like artifactory. Those are more designed for the outputs of builds, whereas git repositories are designed to hold the inputs to builds.

The reason locking merges is discouraged is it incentivizes developers to circumvent the normal process. So you might find them doing things like merging pull requests into each other, or otherwise making their pull requests larger than they normally would, in order to be able to get a pull request off their plate.

| improve this answer | |
  • Thank you for the helpful response, I will take this into consideration. We are looking to commit renamed database migration files; the names are changed from timestamped versioning to sequential versioning. We use the Goose migration tool and this is how it's supposed to work. – Elliott Shugerman Apr 10 '19 at 21:43
  • So, you are versioning the DB schema in the same reposistory than source code. Right? Ca not you make a dedicated repository for these Files? – Laiv Apr 11 '19 at 6:17
  • @Laiv That's an interesting idea, I'll have to give it some thought. – Elliott Shugerman Apr 12 '19 at 18:49
  • 1
    This way, they can also have their own CI cycle and testing. Say you make a little runtime with Java+H2DB to load all the SQL sequentally, make some checks like selects or inserts and destroy the db at the end of the pipeline. – Laiv Apr 12 '19 at 18:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.