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.

QuickBuild

REST call for changes of a build does not deliver results #2858

#1
ronald.brindl ·
We have separated our configurations in two categories: pipeline and build
the pipeline configs only manage what has to be built and trigger the build-configurations.
The pipeline configs only do flat checkouts to show the list of changes, but no details to save time and space (they actually do not build anything and do not need the files), we just need that to get the list of committers.
We have a monitoring app that fetches the build results and displays them in a so called "pipeline overview"

In the pipeline builds in QB in the "SCM Changes > By changeset" we see only a list of changes, but not the details which files have been changed, which is OK.
In "SCM changes > By file" we see nothing (which is also OK).

The problem is now, that when the "pipeline overview" does its REST call to fetch the information of a pipeline build, it gets an empty list for the SCM changes: <list/>
I suppose the reason for this is that the REST call tries to fetch a list "by file", which is empty.

Is there any possibility to get the list "By changeset" via REST?
  • replies 11
  • views 3857
  • stars 0
#2
steveluo ADMIN ·
Hi,

The result returned from changes REST api should include both commits and files information. See our wiki below for details:

http://wiki.pmease.com/display/QB51/Int ... th+Changes

and an sample result from REST:

<list>
  <changeset>
    <user>steve</user>
    <date>2011-06-03T15:11:40.000+08:00</date>
    <id>913fcbcdbe8f80d6c1fe5fce3bb49e1f0040a943</id>
    <comment>
      Fix TST-23: 2-phase load components
    </comment>
    <repositoryName>hg</repositoryName>
    <repositoryType>Mercurial</repositoryType>
    <additional>14</additional>
    <buildId>321</buildId>

    <modifications>
      <modification>
        <action>MODIFY</action>
        <path>Test.java</path>
        <edition>913fcbcdbe8f80d6c1fe5fce3bb49e1f0040a943</edition>
        <previousEdition>f090cd04725c5551f8a439fe0a53591193ea79c3</previousEdition>
        <additional>14</additional>
      </modification>
      <modification>
        <action>MODIFY</action>
        <path>big.java</path>
        <edition>913fcbcdbe8f80d6c1fe5fce3bb49e1f0040a943</edition>
        <previousEdition>f090cd04725c5551f8a439fe0a53591193ea79c3</previousEdition>
        <additional>14</additional>
      </modification>
    </modifications>
</changeset>
	
	... ...
</list>


If there are changes in your build and you can see the changes in "By Changeset", normally it can be fetched from RESTful api. But I'm not very understanding why you have "By Changeset" list, while no "By Files" list? Should there be any changed files in the commits?

Also, is there any error in your QuickBuild server log when you call REST?
#3
greha ·
The pipeline configs only do flat checkouts to show the list of changes, but no details to save time and space

May i ask how have you achieved this?
I tried the non recursive checkout but i don't get any changes - only the current revision.
#4
ronald.brindl ·
@greha:
We just do a checkout on a repository that has "recursive" disabled.
In the "SCM Changes -> By Changeset" list I see all the changesets, but no file information: there is a dash in the icon at the left and you do not get a list of changed files when you hover over it. But we do get the list of committers which is enough for notification.
The "SCM Changes -> By File" stays empty.

@steveluo
Yes, thats what we get for "normal" builds, i.e. builds that do recursive checkouts.
But for the builds with non-recursive (flat) checkouts it is as described: the <list/> stays empty, no changesets in there. (Although I suppose it would contain entries if we had changes in the very root directory of the checkout)
Maybe I also should have mentioned that we use Subversion repostories.
#5
steveluo ADMIN ·
Thank you for updating (especially for mentioning Subversion) and we can now reproduce the problem, I created the issue below and it will be fixed in next patch release:

http://track.pmease.com/browse/QB-2103
#6
jossy ·
Hello!

I tried this change on a test environment and it does not work anymore at all. Ronald just wanted to also have the commits via REST api and now the changes are gone if they are not in the root directory. It worked better before (for us).

We just need the possibility to have a recursive checkout without really checkout the files. Just having a repository to get all changes between the builds. Doing nothing on the workspace.

We are now not able to upgrade to the latest version, because that would break almost everything in our build pipeline.

Alex
#7
robinshen ADMIN ·
So do you mean that you want QB to list all changes of the repository since previous build even if the repository itself is not used for checkout? If so it violates QB assumptions on changes that changes should reflect modifications applied to a build. If a repository is not used for checkout, it is valid for QB to not recording its changes as they are not affecting the build.
#8
jossy ·
Yes exactly. Because we want to have the committers list for notification, the svn commit message and also the revision in the pipeline view.

And we are currently checking out without recursive option to achieve this and not waste too much space for configuration which we just use for the pipeline and for notification.

After thinking of it it is right that this was considered as a bug and now commits are filtered out, BUT it would be much appreciated if there is an option in the checkout step or the repository definition where we can say "do not really checkout files".

Or is there any other way to achieve this?

How would you suggest that we should proceed?

Alex
#9
robinshen ADMIN ·
A workaround is to add a script step to call repositories.get("repo name not for checkout").setCheckout(true); This allows to mark a repository as checked out without adding an actual checkout step. And then QB will record changes of this repo. Of course, you can now turn on the "recursive" option of that repository to allow it capture full changes.
#10
jossy ·
Thank you! I will try this on the test system.
#11
jossy ·
I tried it and it does not work!

I had to do some more magic to also have the changes:
groovy:
def repository = repositories.get("svn-root")
repository.setCheckout(true)
repository.takeSnapshot()
if (!repository.isChangesRecorded() && build.getConfiguration().isRecordSCMChanges()) {
	system.getServerService().writeChanges(build.getId(), repository.getName(), repository.getChanges());
	repository.setChangesRecorded(true);
}


So some setting in Repository which does this would be nice.
#12
robinshen ADMIN ·
I filed an improvement request for this:
http://track.pmease.com/browse/QB-2139
Log in to reply