Your browser was unable to load all of the resources. They may have been blocked by your firewall, proxy or browser configuration.
Press Ctrl+F5 or Ctrl+Shift+R to have your browser try again.

Build Schedule vs. Git Commit Being Part of Build Process #4228

fabb64 ·

I'm using a build schedule to run builds automatically every few minutes in case there are new commits. This would work fine, but I have one build that needs to make a commit during build (we are using lerna which creates a new commit with package version bumps on each package release build). You can see the problem: the next scheduled build sees that there is a new commit and builds again...

I somehow need to break the circle. Is there a way how I can for example retrieve the commit hash of the commit done during the build, and set the associated repository commit of this build that newer commit?

I have one more complication: I'm using Docker for building, so the git commit is made inside a docker build, which means the QuickBuild build does not yet know about the new commit. I think I would need to pull the newer commit first in the QuickBuild build (but probably not the branch tip to avoid it referencing a wrong commit in case there have been made newer commits in the meantime while the build was running).

Any ideas how to approach this?

  • replies 8
  • views 3433
  • stars 1
robinshen ADMIN ·

Assume these auto-commit during build has some special commit message, for instance starts with "autocommit:". Then you can edit build condition of the configuration to evaluate below script:

groovy:
for (changeset in repositories.get("your git repo").getChanges()) {
  if (!changeset.comment.startsWith("autocommit:"))
    return true;
}
return false;
fabb64 ·

Are you sure this works as expected when my build is not always running on the same build node? Documentation of getChanges() is not really clear on which changes it includes: "Get current changes in the repository. Changes are sorted with latest change being the first element."

Does it include the changes compared to the last build, even if that last build ran on a different node than the current build?
Or do we additionally need to use the revision of build.getPreviousSuccessful() combined with getChangesSince()?

robinshen ADMIN ·

When getChanges() is called, QB will sync git repository on the node running the master step and then calculate changes since previous build, in regardless on which node build is running. Please give it a try to see if it works for your scenario.

fabb64 ·

Sounds good, thanks! I already have it in place and observe its behavior.

QuickBuild needs better docs. Such details seem to be nowhere mentioned. The JSDoc would be a good place for that.

robinshen ADMIN ·

Let me know if it works, and I will add it into our online tutorial.

fabb64 ·

It looks good so far, though we didn't yet have the case that it ran on different build nodes. Also it might not ideal when the last build failed, because as far as I have understood, getChanges() will only return the commits since that last commit, and therefore it's probably not possible to re-run a failed build manually. But that doesn't hurt too much in our case.

robinshen ADMIN ·

Below condition will detect changes since last successful build:

groovy:
def lastSuccessful = configuration.getLatestSuccessfulBuild;
if (lastSuccessful != null) {
  for (changeset in repositories.get("your git repo").getChangesSince(lastSuccessful)) {
    if (!changeset.comment.startsWith("autocommit:"))
      return true;
  }
  return false;
} else {
  return true;
}
fabb64 ·

Nice, thanks!