Ability to remember last known good build

Ability to remember last known good build

[Pedroso, Osiris]

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?

Appreciate any comments,
Osiris Pedroso

Re: Ability to remember last known good build

[Junio C Hamano]

"Pedroso, Osiris" <osiris.pedroso@intergraph.com> 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"?

Re: Ability to remember last known good build

[Stefan Beller]

On Fri, Mar 11, 2016 at 10:08 AM, Junio C Hamano <gitster@pobox.com> wrote:
> "Pedroso, Osiris" <osiris.pedroso@intergraph.com> 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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: Ability to remember last known good build

[Randall S. Becker]

On March 11, 2016 1:08 PM Junio C Hamano wrote:
> "Pedroso, Osiris" <osiris.pedroso@intergraph.com> 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(211288444200000000)
-- In my real life, I talk too much.

Re: Ability to remember last known good build

[Junio C Hamano]

Stefan Beller <sbeller@google.com> 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.