On 5 June 2013 12:27, Emmanuel Bernard <emmanuel(a)hibernate.org> wrote:
For now I cloned a search job, created a Personal runs view, added a
GitHub notification from my personal fork and pushed results as IRC
Not too bad so far after the initial phase where Jenkins decided to
build on all my already existing branches :)
Question, is this config going to survive a ci.hibernate.org
Depends on the kind of crash; the kind of disk storage we're using
survives a crash or restart of the VM, but could still be lost
depending on how bad AWS is doing.
The ultimate backup is adding this to the generation scripts we
maintain on github - but that's requiring some puppet expertise - A
good practical solution is to make snapshots of the AWS running disk.
I've just made one, so your new job is being stored now.
To make snapshots you can use the AWS console via your browser and
navigate to Volumes or Snapshots. These snapshot features are super
practical as you can use them to start new VMs.
On Wed 2013-06-05 9:38, Sanne Grinovero wrote:
> I also was thinking of creating a personal job there which would
> monitor a specific branch name on my personal github fork, maybe
> "toTest" or "forJenkins".
> Another option is to use parametric jobs: you have to trigger them
> from the UI and the wizard will ask you to fill in a couple of
> parameters which are applied to the build configuration; these could
> be for example 1- repository 2- commitId
> That could allow us to have a single job per project for all of us;
> ideally this could be started by REST too, so making some script
> possible to trigger it from your local box commandline.. it would be
> trivial to have such a script auto-detect the needed parameters.
> I'm not sure how such a script would deal with authentication: we
> require authenticated users to trigger jobs manually. I think you
> could obtain an OAuth token from the github server to use on Jenkins,
> using the Github feature of creating application specific passwords
> (which you would then set as a constant in your script).
> If we get the REST variant to work it would be great to provide it as
> a service of the build tool (not thinking of Maven here): we could
> have, on top of traditional tasks such as "install", "release",
> "test", also "remote-test". This would be especially cool for ORM
> OGM developers as you could get feedback from the full range of
> databases without installing them locally.
> On 4 June 2013 23:39, Steve Ebersole <steve(a)hibernate.org> wrote:
> > Lol, was just going to say this ;)
> > You can clone the Jenkins job and point it at your branch. Not so sure
> > I want this to happen automatically for all my branches.
> > On 06/04/2013 05:36 PM, Gunnar Morling wrote:
> >> If you just want an ad-hoc solution, you could create a copy of the HSEARCH
> >> job and change it to let it build your branch. I'm doing it like that
> >> once in a while.
> >> --Gunnar
> >> 2013/6/5 Emmanuel Bernard <emmanuel(a)hibernate.org>
> >>> With the CI slowly getting in place. Would there be a way to test a
> >>> branch of mine without having to push it as a pull-request?
> >>> When I push a branch on emmanuelbernard/hibernate-search.git without
> >>> creating a PR, it would still be nice to be able to have it run.
> >>> Thoughts?
> >>> _______________________________________________
> >>> hibernate-dev mailing list
> >>> hibernate-dev(a)lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >> _______________________________________________
> >> hibernate-dev mailing list
> >> hibernate-dev(a)lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> hibernate-dev mailing list