"Pedroso, Osiris" [off-list ref] 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"?
On Fri, Mar 11, 2016 at 10:08 AM, Junio C Hamano [off-list ref] wrote:
"Pedroso, Osiris" [off-list ref] writes:
quoted
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 majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On March 11, 2016 1:08 PM Junio C Hamano wrote:
"Pedroso, Osiris" [off-list ref] writes:
quoted
I participate in an open source project that any pull merge is accepted,
no
matter what.
quoted
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.
quoted
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.
quoted
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".
quoted
I am new to git, but some other experienced co-volunteers tell me that
it
may not be possible due to authentication issues.
quoted
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(211288444200000000)
-- In my real life, I talk too much.