staging branch

[Barret Rhoden]

Hi -

I'm going to try using a 'staging' branch for a little while. In
general, anything I'm merging will go there and it'll sit for a little
bit before getting pushed to master.

That ought to give people a chance to try things out and find problems
before it hits master. If someone wants to set up a jenkins job to do
builds or tests, then it can run on staging.

In general, anything I push to staging won't get merged to master until
the next day. If this ends up being more of a pain than a good thing,
I can stop doing it too.

Barret

[Davide Libenzi]

At my previous job, we had a Jenkins job which, before running, would ask the name of the branch you wanted to run off.

For 98% of the cases, that was not necessary, because all the upper layer code was system agnostic.

But when I did changes to the cross platform layer, that turned out very useful, because it allow running regressions on 8 different combinations of OSs at the same time.

If we end up having a CI infrastructure, that would be ncie to have.

Though, we first have to have tests, because w/out those, there is no Jenkins job which can catch them ☺

Barret

--
You received this message because you are subscribed to the Google Groups "Akaros" group.
To unsubscribe from this group and stop receiving emails from it, send an email to akaros+un...@googlegroups.com.
To post to this group, send email to aka...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[ron minnich]

Now that we have an organization for akaros one option is to set up travis-ci.org as we did for Harvey. 

Let me know if that sounds interesting. I'd also like to get us on coverity but that can wait.

ron

[Davide Libenzi]

Nice, I did not know that.

[Kevin Klues]

> Now that we have an organization for akaros one option is to set up travis-ci.org as we did for Harvey.

If you think travis is better I'd say go for it. Otherwise we have
the jenkins stuff we did a few years ago I can revive and host at
ci.akaros.org. Will travis be able to support all our needs? If so,
ci.akaros.org can just be a redirect to our travis-ci account.

Kevin

[Dan Cross]

+1 for ci.akaros.org....

[Kevin Klues]

> Now that we have an organization for akaros one option is to set up travis-ci.org as we did for Harvey.

Also..
Yes we have an organization. No we're not using it yet...

[ron minnich]

I think as in all things the first person to implement ci wins. Each path has advantages, but what matters in the end is that we do one of them :-)

ron

[Kevin Klues]

Not set up properly yet for our stuff, but...

http://ci.akaros.org/

--
~Kevin

[ron minnich]

Now here's the big question: can I log into that thing and just test the VM capabilities it has? 

Or how to I set up a test? I've forgotten.

ron

[Davide Libenzi]

I never setup one, but I know ours were basically shell scripts.

They would fetch git repos (and eventually checkout branches in them), setup the environment based of Jenkins job config, run the build, and package the artifact.

Then a chained job would pick up the artifact, and run many tests in it.

These shell scripts are sent to Jenkins slaves, and run there, with the master controlling them.

IIRC the shell script exit status determines the job success/failure status. 0 == OK.

[ron minnich]

for coreboot, every commit results in a build of all 300 or so mainboards. Any build failure will block a commit.

For NxM, we built all libraries, binaries, and kernels, built and booted, and ran regression tests (this being Plan 9, that full process took 2 minutes ...). Failure at any point blocked commit. Boy was that nice.

For Akaros I'm pretty sure we had something similar, but have no mechanism by which a jenkins failure could block a commit. It would be advisory, but still very useful.

ron

[Xiao Jia]

maybe we can have a stable branch and a next branch, and cherry pick "known good" commits from next to stable, and make sure stable can always compile/boot/...

most of the time when nothing bad happens, this could be done automatically by a script, on a daily/weekly/... basis.

--

[Kevin Klues]

I can set up jenkins to follow the staging branch, run tests whenever
a new push is made to it, and then rebase those changes onto a
different branch whenever all tests pass. I assume the process would
go:

1) Barret merges some changes into the staging branch
2) Jenkins spins up and runs our full test suite on the staging branch
3) Assuming things pass, Jenkins rebases the staging branch onto some
other branch (what should we call this? -- stable as xiao suggests?)
4) Barret merges the changes from 'stable' into master

Alternatively, jenkins just pushes to master directly, bypassing the
need for a 'stable' branch.

--
~Kevin

[Davide Libenzi]

In my previous job, we just made it run N times a day, independently.

There were, any given day, quite a few change-sets being pushed, so the timed run would somehow batch them instead of triggering as soon as it was a commit, when another one was in the pipeline to come 5 minutes later.

The setup was different though. After the code review process completed (the developer verified unittests and regression tests passed), the developer would just push directly to master.

[Barret Rhoden]

On 2015-10-18 at 12:53 Kevin Klues <klu...@gmail.com> wrote:
> I can set up jenkins to follow the staging branch, run tests whenever
> a new push is made to it, and then rebase those changes onto a
> different branch whenever all tests pass. I assume the process would
> go:
>
> 1) Barret merges some changes into the staging branch
> 2) Jenkins spins up and runs our full test suite on the staging branch
> 3) Assuming things pass, Jenkins rebases the staging branch onto some
> other branch (what should we call this? -- stable as xiao suggests?)
> 4) Barret merges the changes from 'stable' into master

Steps 1, 2, and 4 is basically what I'm looking for with the stable
branch. The delay between staging and master provides everyone a
chance to try things out, including, but not limited to the Jenkins
machine. (Someone else could come up with something that Jenkins
missed, for example).

Barret

[Xiao Jia]

http://homu.io/ sounds related.