Re: Ability to remember last known good build
Stefan Beller writes: >>> Any better way of accomplishing this? >> >> "test && git branch -f last-good"? > > Travis-CI enabled, tells me they're using Github and are distributed, > so one contributor would want to know the last known good state of > a remote, that others push to, without testing all commits locally. > > So maybe the question is better rephrased as: "How do we keep track of > the last good state using the distributed nature of Git?" I think Travis integration with GitHub lets the commits tested to be annotated in the test status, so scanning the history from the tip to find the latest one with the "good" test result would be how you would find "the last passing one" if your workflow relies on the Travis-GitHub combination. I am not sure about "using the distributed nature" part. That depends on the way how the result of the Travis testing is reflected on the GitHub side. If it is done by adding a note or something that can natively exported over "git fetch", that would be one way to do so. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Ability to remember last known good build
On March 11, 2016 1:08 PM Junio C Hamano wrote: > "Pedroso, Osiris" writes: > > > I participate in an open source project that any pull merge is accepted, no > matter what. > > > > This makes for lots of broken builds, even though we do have Travis-CI > enabled on the project, because people will merge a request before even the > build is complete. > > > > Therefore, I would like to remember the id of the commit of the last > successful build. This would be updated by the Travis-CI script itself upon a > successful build. > > > > I imagine best option would be to merge master to a certain branch named > "Last_known_Linux_build" or "Last_known_Windows_build" or even > "Last_known_build_all_tests_passing". > > > > I am new to git, but some other experienced co-volunteers tell me that it > may not be possible due to authentication issues. > > > > Any better way of accomplishing this? > > "test && git branch -f last-good"? I think semantically a last-good tag might be another option, unless you are applying build fixes to a last-good topic branch. You also have the option of adding content to the tag describing the build reason, engine used, etc. See git tag --help. I have used that in a Jenkins environment putting the tag move in the step following a build (failure does not execute the step so the last-good build tag stays where it is). Cheers, Randall -- Brief whoami: NonStop&UNIX developer since approximately UNIX(421664400)/NonStop(2112884442) -- In my real life, I talk too much. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Ability to remember last known good build
On Fri, Mar 11, 2016 at 10:08 AM, Junio C Hamano wrote: > "Pedroso, Osiris" writes: > >> I participate in an open source project that any pull merge is accepted, no >> matter what. >> >> This makes for lots of broken builds, even though we do have Travis-CI >> enabled on the project, because people will merge a request before even the >> build is complete. >> >> Therefore, I would like to remember the id of the commit of the last >> successful build. This would be updated by the Travis-CI script itself upon >> a successful build. >> >> I imagine best option would be to merge master to a certain branch named >> "Last_known_Linux_build" or "Last_known_Windows_build" or even >> "Last_known_build_all_tests_passing". >> >> I am new to git, but some other experienced co-volunteers tell me that it >> may not be possible due to authentication issues. >> >> Any better way of accomplishing this? > > "test && git branch -f last-good"? Travis-CI enabled, tells me they're using Github and are distributed, so one contributor would want to know the last known good state of a remote, that others push to, without testing all commits locally. So maybe the question is better rephrased as: "How do we keep track of the last good state using the distributed nature of Git?" I would rather ask the more fundamental question of the workflow of having everything merged despite tests failing. Also accepting pull requests no matter what, sounds suspicious to me. (Can I sneak in security issues or delete all files and it still is pulled?) > -- > To unsubscribe from this list: send the line "unsubscribe git" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Ability to remember last known good build
"Pedroso, Osiris" writes: > I participate in an open source project that any pull merge is accepted, no > matter what. > > This makes for lots of broken builds, even though we do have Travis-CI > enabled on the project, because people will merge a request before even the > build is complete. > > Therefore, I would like to remember the id of the commit of the last > successful build. This would be updated by the Travis-CI script itself upon a > successful build. > > I imagine best option would be to merge master to a certain branch named > "Last_known_Linux_build" or "Last_known_Windows_build" or even > "Last_known_build_all_tests_passing". > > I am new to git, but some other experienced co-volunteers tell me that it may > not be possible due to authentication issues. > > Any better way of accomplishing this? "test && git branch -f last-good"? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
