[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: A case for layered development/build/test/deployment tools.






On Wed, Mar 20, 2013 at 2:12 PM, John Reuning <john ibiblio org> wrote:
Mark,

I like where this is going.  In case someone is collecting data
points, here are my use cases.

This by itself doesn't solve all of your points:
 

* I have a pilot project for an on-prem instance running on centos 6,
which means I'm building from source.  I hacked the dev tools code but
would like to not maintain a fork.

 
* All my yum repos are local.  I can't use the yum configs written by
the dev tools, and I can't use external repos directly.

I'm assuming you can at least get rsync copies periodically.  Nothing about this change will fix the fact that we still have custom
pacakages in mirrors that are working their way upstream. (see activemq)

 
* I don't have a cloud and need to reuse the build server.  Puppet
ensures the dependencies exist on the build server.  It would be nice,
however, if the dev tools could validate the build environment and
just report the results.

I haven't found a "just tell me" mode on yum-builddep.  It tries to install everything and will comment on anything that's already installed.
 
* I also want to build origin as a regular user, which means the dev
tools shouldn't run yum commands.

THere are some cases that need it (installing builddeps) but my goal is that those cases should be distinct from others that don't.
 
* The destination yum repo for origin rpms is external to the build
server, so I don't need to write the rpms to a local repo and install
the newly-built rpms on the build server.

assuming you can install a simple web server like thttpd on your build server, it can publish the packages as well.


See  http://cloud-mechanic.blogspot.com/2013/03/the-bleeding-edge-building-openshift.html
(the last couple of steps)

You could also automate an rsync with periodic and triggered actions.

* I like the idea of using mock and other fedora build tools, but I
don't have the time to set that up.  I'd prefer the origin dev tools
not require the fedora build tools.

The packages should probably have more unit tests built into the source trees.  Running the tests would then add one new target:

   rake test (or rake spec, depending on the convention established)

Then you could both run the included tests and add your own as you make changes.
 
One of my considerations is whether to add a standard "test" target to the rake task templates.

Thanks,

-John

_______________________________________________
dev mailing list
dev lists openshift redhat com
http://lists.openshift.redhat.com/openshiftmm/listinfo/dev



--
----
Mark Lamourine <markllama gmail com>
Dad, Hubbie, Software Developer, System Administrator, Road Cyclist

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]