A general solution sounds good, but I want to keep the votes of this ticket:)

Any idea when this feature will be implemented? A hole product of us (>30 developer) will not switch to GIT before this feature is done. Please! go for it!

Any opinions on implementing this issue vs TW-8326 ?

TW-8326 seems to be the better option. The commit shouldn't go into the "trunk" like you commented it. The commit should go into the branch where the remote-run runs against. To sum it up:

A TC configuration has an option: "pre-tested commits only = true|false"
If true and if you push s.th. from your local machine against origin "BranchX" a "remote-run" is triggered.
If the run is successful the changes are committed into "BranchX".
If the run fails the changes are NOT committed.

One question: When you have un-pushed and un-committed changes and start a remote-run, what should happen if it fails?
a) the un-committed changes remain un-committed and are moved into a change-set
b) the un-committed changes are committed into your local repo

Option a) seems to be more complex, but might be a cool feature. IMO a exciter, so nothing for now:)

What did you think?

Hi,

Some thoughts, because I am a bit confused by the terms used in both tickets:

"commit"

• A commit in git happens just locally on my machine. If this is what is meant by commit I would not want a personal build at all.
  
• If commit means push to a remote repository, then this is where I would like to trigger a personal build
  
• But I would like to be able to push more then one commit at once

"trunk"

• There are at least two trunks involved and lets call them local master and remote master.
  
• The personal build should not change my local master at all
  
• If I intend to push the local master to a remote repository, then the personal build should validate the content of the push and automatically proceed with the push to the remote master, when the personal build is ok
  
• The same is true if I would like to push to a remote branch, so there is no difference between master and branches

In summary, the feature I would like is to trigger a personal build before I push my commits to a remote repository. If this personal build fails I want no push to happen. If the personal build is successful I want the push to proceed automatically.

I guess both tickets do not really describe that behaviour, but this one here comes closest.

Joerg,

Yes, there is some confusion in the terms. Mostly because what is "commit" in a classic VCS becomes/should be "push" in DVCS.
The difference between the tickets is that this one (TW-11344) is about implementing pre-tested commit as IDE-originated logic (allow user to select what to test, send to TeamCity, optionally try to push to a remote) and TW-8326 is about server-originated logic (when user pushes the changes into a designated branch, run a build on them and optionally try to push into another (master) branch).

This is a kind of technical difference in implementation but the implementation here implies a lot on what is possible and what is not and also what tools are used to perform the pre-tested commit.

Leif,



The current vision (it's not yet implemented) is that the files should probably be committed in the moment of remote run originating and if it was a "pre-tested commit", then the committed changes should be pushed into the remote. If not, the files just sit committed in the local repo. The idea here is that "pre-tested commit" is to protect shared repo from bad changes, not local repo from bad changes.

Yegor,
agreed, so it is option b) if you run "commit and push" :)

I would recommend not to use the server originated logic. We also thought about it because it could even be realized without any changes to Teamcity, but we did not do it for the following reasons. I hope I can explain them here well enough, because it is a bit complicated.

You will have effectively two different remote-repositories (or branches) for pull and for push:

• The "green" repository is the one where Teamcity will push the changes after successful personal build. This is the one you pull all your changes from.
  
• The "push" repository is the one, that triggers the personal build. It must be different from the "green" repository. Otherwise it would just be classical CI.

The first issue is, that these different remotes need to be configured in your local git settings. Not a big deal, but still a source for a lot of confusion and I bet a source for many support tickets :)

There can be one "push" repository for all developers or an individual "push" repository for every developer. You would not want to do the first. Because this would only allow one personal build at a time. This is because you can not remote merge and if there is a personal build running, then the green repository, where you pull from, does not have the same commits as the push repository.
You can have a push repository per developer. You would still have an issue if two people run a personal build at the same time and push afterwards, but then you got at least the same behavior like with subversion at the moment.

The IDE originated logic would behave the same way, but would be less complex I guess.

Regarding your answer to Leif. I totally agree that only locally committed changes should be included in a personal build. Otherwise you would also have to deal with issues like the git stage concept, which makes it much more difficult to understand.

I like TW-8326 more and more. Specially if you can configure your TC-Branch-Config with a boolean Flag that always run pre-tested. No more broken build by accident.

Joerg,

Thank you for sharing the considerations.

Some raw thoughts:


Yes, if they are just different branches, then a developer should decide whether to push into green or into "push" branch. Dedicated IDE VCS support can probably ease the task.


If these are just different branches, then it seems OK to monitor any branch with a name matching a pattern (like "remote-run-.*"). Thus, making it remote run branch per developer.
The issue here is how the changes are then pushed after they are verified. If there are no intersection on the edited files they can probably be pushed either with merge or rebase. If there is a conflict on files, then it will obviously produce an error message.

Yegor,


I have some difficulties to imagine how this will work when you have remote feature branches. In some of our projects we do not always push to remote master, but have long-living feature branches. How will Teamcity decide, which branch to merge to after a successful personal build?


I think you should not be able to push into a "green" branch. At least not, when following this model. Otherwise the "green" branch is not guaranteed to be green.

Joerg

I tried to write down the most common use cases - see attachment remote-run.pdf. While writing it down it seems to me as if the IDE-originated solutions would be sufficient. It will ensure a green origin repo when using TC. In order to fulfill these use cases you need to fix IDEA-54162 (and IDEA-53431). Maybe you can draw a little diagram as well for the alternatives. Best regards, Leif

Leif,

Thank you for the diagrams.
Do you mean that pulling is performed manually or automatically?

The option to do it automatically sounds good. Offer both alternatives:)

Yegor, is this issue scheduled meanwhile?