Hello,
We would like to be able to use the queue immediately, but that forces us to this option:
Why is this descision made? We would love to see all changesets since the last succeeded build so we know what has been fixed in a build, whether it's "queue immediately" or not.
Thanks!
Not entirely sure, my best guess would be it was perhaps done for performance reasons a long time ago. I will discuss with the team to see if there are any reasons we shouldn’t change it.
Thanks for the reply. I also have the feeling that there is a bug when queuing a build. This can have 2 reasons which I can think of now:
1) Using TFS, it can take quite a while to retrieve the history. If you store the timestamp of when the item has last succeeded (thus the end of the check), the commits between the start of the check and end are not found. It is best to store the last time when you started the check, not when you finished it.
2) The queue immediately does not force a repository check (and thus not get the latest change).
Since I have no source I cannot tell you the exact reason, but it should be fairly easy for you to figure out which of the 2 it is.
Hi Geert,
We immediately check for new changesets when a build is triggerred and we retrieve the TFS history based on the last changeset id rather than a timestamp.
Can you provide more information on your issue? Are you missing a changeset after manually starting a build or for a build started by a trigger? Can you provide details of the repository and trigger settings? A debug log may also help us to identify what id going wrong.
Hmmm, can’t reproduce it with the latest version (released January 9th). I have enabled logging and now the problem does not occur.
Checking the repositories now also takes much longer (it immediately started before, now it takes about 30 seconds to check a repository and it sees all changes). Did you change anything around this area in the latest build?
I tried it several times, now it did not find the latest change. What I did was:
1) Check in something
2) Immediately start a new build (queue immediately)
3) Check changes in repository (no changes, not in the build nor in the configuration changes)
Note that we use the same repository over multiple configurations. Can it be that if a build is already running with a repository, that it won’t update until completed?
The log doesn’t provide enough information (cannot see that a build has started for example). Even with debug logging on for the server.
About the tfs timings:
1) Get items from tfs repository: 8 s 375 ms
2) Get branches list: 46 ms
3) Deleting folders: 109 ms
4) Creating directories: 265 ms
5) Getting source: 2 s 250 ms
Time taken getting source files and cleaning up old source files simultaneously for TFS repository path: 52 s 579 ms
Hi Geert,
We have not managed to replicate this issue. Does the change eventually appear for the configuration or does never turn up? It may be that there is a delay in TFS before the check-in appears in the history. If you send the debug log the support@finalbuilder.com, this should help us to work out what is going wrong. Also, can you tell about your repository settings? Are you monitoring branches?