continuum-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brent Atkinson <batkin...@apache.org>
Subject Re: Problems with Continuum making it useless (Dev only)
Date Sun, 03 Mar 2013 17:59:28 GMT
Murali, I'm not saying that shell builds aren't useful, of course they are.
It's more that Continuum's focus hasn't been on these cases and it shows.

I'm asking more about refocusing the project. We could continue to chase
the general-purpose CI tool goal, but other CI tools already do this and do
it better. As you said before, providing a solution for everyone's case is
difficult. Alternatively, you can focus on doing less and doing it well.
Being realistic about Continuum's state and its place among the greater CI
tooling landscape and setting direction based on what it does well provides
an opportunity to re-validate its reason for existence. Communicating out
more accurately what Continuum is attempting to address also makes it more
likely for a functional community to exist around it, and less frustration
all-around.

Without refocusing, I'm doubtful but could be convinced that Continuum has
a place.

Brent

On Sun, Mar 3, 2013 at 8:03 AM, Louis Smith <dr.louis.smith@gmail.com>wrote:

> Actually, we never use the shell builds - even for shell builds.  all our
> shell work is done via ant-run under a pom...IIRC, we did run into issues
> with the "native" shell support - and defining everything (yeah, had to
> write a standard to implement using it that way..) in a
> Groupid/ProjectId/Version based system allowed us to implement the POM for
> the project.  The Oracle Forms we do are just shell commands; even our
> daily run of Apache Forrest runs a large shell script with jar files,
> SVNKit analysis - and "wraps" all the site reports under a nice umbrella.
>  I might upgrade from Forrest to Lenya one of these days... just for fun.
>
>
> On Sun, Mar 3, 2013 at 2:49 AM, murali mohan <muralihere@gmail.com> wrote:
>
> > The shell builds are necessary alongside maven builds. One can never
> image
> > all possible situations for a continuous integration possible around the
> > world. In our case, shell builds are necessary just to support maven
> > builds.
> >
> > As you rightly said, Continuum is mainly for maven builds and that is
> what
> > we are using it for too. But we also need some support and shells are
> very
> > basic and can provide all kinds of support needed and actually close off
> > many use cases, I think. So my vote is for Shell build support - nothing
> > advanced.
> >
> > Anyways, I think I have found the root cause for that issue, which is a
> > "syncrhonize" method, which is not present for other builds like maven. I
> > do not see a reason for synchronize to be present in that method as
> > explained in the JIRA issue.
> >
> > I can provide a patch.
> >
> > Please have a look and let me know.
> >
> > Thanks,
> > Murali
> >
> >
> >
> > On Sun, Mar 3, 2013 at 12:45 AM, Brent Atkinson <
> brent.atkinson@gmail.com
> > >wrote:
> >
> > > Thanks murali, I'll see if I can dig up what root issue might be and
> > update
> > > the issue.
> > >
> > > IMO Continuum's shell and ant support seems a little bizarre because
> the
> > > concepts in the application, projects and project groups, were taken
> > > directly taken from Maven's concept of groupId (group) and
> > > groupId+artifactId (project). The concepts aren't clear to someone not
> > > versed in Maven and the implementation seems directed to the Maven
> > concepts
> > > anyway. I also noticed that the ant support was a bit broken a while
> back
> > > depending on how you added projects. It seemed so broken that I
> couldn't
> > > imagine anyone using them.
> > >
> > > I am wondering, would it be better to prune and cultivate what people
> are
> > > using than to drag along vestigial limbs?
> > >
> > > As for interest, thanks Louis for speaking up. I believe that there is
> > > still room for a product that directly addresses CI for Maven
> projects. I
> > > use both Continuum and Jenkins, and I still like the simplicity of
> being
> > > able to add projects via poms, manage things through the pom, etc. Not
> > all
> > > projects can operate within the conventions, so the audience may be
> > smaller
> > > than other CI tools from the start, but I think not trying to solve
> > > everything might actually sanitize (both clean and sane) things.
> > > Personally, I think it would be great to do in things like push-button
> > > branching using release:branch (with version conventions like
> maintenance
> > > branches, release branches, etc.) and have the branched build added for
> > > you.
> > >
> > > To your earlier point murali, if the tool seems like it is offering a
> > > solution and doesn't work properly, it doesn't inspire confidence. I
> can
> > > say from direct experience that Continuum actually does work well for
> > > conventional Maven builds and if the others aren't a focus and are
> > broken,
> > > why keep fooling ourselves and users?
> > >
> > > Brent
> > >
> > >
> > >
> > >
> > > On Mar 1, 2013 9:54 AM, "murali mohan" <muralihere@gmail.com> wrote:
> > >
> > > > Created a new JIRA issue at
> > > http://jira.codehaus.org/browse/CONTINUUM-2704
> > > >
> > > > I have done a little analysis and posted as comment. Please guide me
> on
> > > how
> > > > to proceed and I will try when I get time.
> > > >
> > > > Thanks.
> > > >
> > > >
> > > > On Fri, Mar 1, 2013 at 11:51 AM, Louis Smith <
> dr.louis.smith@gmail.com
> > > > >wrote:
> > > >
> > > > > I have continuum installed at several clients - one of whom runs
> over
> > > 100
> > > > > java projects and 20 Oracle Forms projects with it.  We have
> upgraded
> > > to
> > > > > the 1.4.x release and have had nothing but success with it - so
> count
> > > me
> > > > > and my clients as "interested".
> > > > >
> > > > > Louis
> > > > >
> > > > >
> > > > > On Fri, Mar 1, 2013 at 5:52 AM, murali mohan <muralihere@gmail.com
> >
> > > > wrote:
> > > > >
> > > > > > As an immediate solution, I will have to look at other options,
I
> > > > guess.
> > > > > >
> > > > > > To solve these, I will try to help. But are people interested
in
> > this
> > > > > > project?
> > > > > >
> > > > > >
> > >
> > >
> > >
> > > > -Murali
> > > > > >
> > > > > > On Thu, Feb 28, 2013 at 5:53 PM, Brent Atkinson <
> > > batkinson@apache.org
> > > > > > >wrote:
> > > > > >
> > > > > > > Hi Murali,
> > > > > > >
> > > > > > > I'm sorry that you're frustrated.
> > > > > > >
> > > > > > > I doubt I can address everything you're raising as I'm
still a
> > > > relative
> > > > > > > newbie in the code base, but I do know that there are a
number
> of
> > > > cases
> > > > > > > Continuum doesn't handle, at least without workarounds,
in its
> > > > current
> > > > > > > state. One of them is dependencies between builds and I
wonder
> if
> > > > this
> > > > > > > limitation is responsible for why the parallel builds work
this
> > > way.
> > > > > > >
> > > > > > > To be perfectly honest, if you are looking for an immediate
> > > solution,
> > > > > > > Continuum may not be the best choice for you. However,
if
> you're
> > > > > > interested
> > > > > > > in helping to address the issues, I will do what I can
to help.
> > > > > > >
> > > > > > > Brent
> > > > > > >
> > > > > > > On Thu, Feb 28, 2013 at 4:21 AM, murali mohan <
> > > muralihere@gmail.com>
> > > > > > > wrote:
> > > > > > >
> > > > > > > > Warning. This is a rant.
> > > > > > > >
> > > > > > > > -> Parallel builds in Continuum is an embarrassment.
Reasons:
> > > > > > > >
> > > > > > > >    1. Different builds from the same project cannot
be queued
> > if
> > > > one
> > > > > of
> > > > > > > >    them is already running. Why is this? It is not
even the
> > same
> > > > > build,
> > > > > > > it
> > > > > > > > is
> > > > > > > >    a separate buildsbut belonging to the same project.
This
> is
> > a
> > > > > block
> > > > > > > > since
> > > > > > > >    we are forced to time the scheduling perfectly
so that the
> > > > second
> > > > > > > build
> > > > > > > >    starts only after first build is done. Why?! Or
we need to
> > > have
> > > > > > > separate
> > > > > > > >    project groups. Then why do we need projects?!
> > > > > > > >    2. Shell builds are not running in parallel in
version
> 1.3.6
> > > > > (Don't
> > > > > > > know
> > > > > > > >    about other versions). Even after enabling parallel
builds
> > and
> > > > > > queues
> > > > > > > > and
> > > > > > > >    when maven builds run in parallel without any problem.
> > > > > > > >
> > > > > > > > It has become a very clever and unknown science now
to run
> all
> > > the
> > > > > > builds
> > > > > > > > in parallel in continuum and to ensure that everything
> > completes.
> > > > > > > >
> > > > > > > > -> There are thousand of builds and their history
in our
> > > continuum
> > > > > > > setup. I
> > > > > > > > have set up purge configurations, but still the UI
lists
> > > thousands
> > > > > and
> > > > > > > > takes a long time to load.
> > > > > > > >
> > > > > > > > -> For both the above, I have sent emails to support.
One is
> > > > recent,
> > > > > so
> > > > > > > > lets leave that, The deletion of builds - no help
to complete
> > it.
> > > > > Some
> > > > > > > > vague suggestions which never worked when I tried.
There is
> > some
> > > > XML
> > > > > > RPC
> > > > > > > > tool to delete these old builds. I did spend a couple
of days
> > to
> > > > run
> > > > > > it,
> > > > > > > it
> > > > > > > > doesn't!
> > > > > > > >
> > > > > > > > -> Yes, this is open source and we all should contribute.
> But I
> > > am
> > > > > > > someone
> > > > > > > > who has submitted patches before and willing to spend
some
> > time.
> > > > But
> > > > > > > there
> > > > > > > > seems to be no people who are running this or being
> > responsible.
> > > > > > > >
> > > > > > > > -> All in all, I have spent a lot of time on this
software
> from
> > > the
> > > > > > time
> > > > > > > > when it had very minimal features. Sadly, I think
it is a
> waste
> > > of
> > > > > time
> > > > > > > now
> > > > > > > > adjusting schedules and making it "somehow" run.
> > > > > > > >
> > > > > > > > -Murali.
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Dr. Louis Smith, ThD
> > > > > Chief Technology Officer, Kyra InfoTech
> > > > > Engineer-in-Training, Veterans Memorial Railroad
> > > > >
> > > >
> > >
> >
>
>
>
> --
> Dr. Louis Smith, ThD
> Chief Technology Officer, Kyra InfoTech
> Engineer-in-Training, Veterans Memorial Railroad
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message