ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Brown <tpbr...@gmail.com>
Subject Re: Publishing C-module artifacts from different platforms
Date Thu, 13 Jan 2011 15:21:19 GMT
Felix,

But if it's a single source base, for multiple platforms, wouldn't building
and publishing for a single platform be considered not fully tested?

If the developer wants to share his WIP code with another, why wouldn't he
just use a patch instead? [or, build it for the other platforms, test it,
then commit it all so that CI does it's job]

side-note: yeah, you can do the build pipeline similar to Shawn's with
Hudson [and Go, and Bamboo, etc.]

On Wed, Jan 12, 2011 at 11:23 PM, Felix Drueke <fdrueke@orga-systems.com>wrote:

> Shawn, thanks for that valuable input.
>
> I assume we're going for a pretty similar procedure.
> We're using Hudson to verify that the build still works on all platforms
> and compilers.
> So I guess it's also possible to have Hudson publish the artifacts right
> away
> (didn't try that yet).
>
> However there's still one reason why I think that artifacts for just one
> platform should be publishable (at least for dev-snapshots).
> That is if a developer wants to publish the results of his latest work
> in his current workspace. In that case he'll just want to publish for
> just one platform and that's sufficient in that situation.
>
> Felix
>
>
> Shawn Castrianni wrote, on 01/12/2011 05:19 PM:
>
>  I can't answer your question, but I can tell you how I handle this.
>>
>> I felt it was a bad idea to publish a partial module such that one
>> platform's artifacts are present and other are not.  If this happens because
>> of a compiler error on one platform but not others, then you can get into a
>> bad situation.  Such as, someone saying that my new feature works on linux
>> but not on windows, not knowing that it works on linux because the new
>> feature was compiled successfully on that platform and he is using the new
>> published module.  But when he tries on windows, he is picking up on old
>> published module since a new one with windows artifacts is not present due
>> to the compile error.  Stuff like that.
>>
>> Therefore, what I do is just as you describe, using separate configuration
>> for each platform.  But then I use a good automated build system (QuickBuild
>> 3.1) to wrap ivy commands.  So my QB build workflow is:
>>
>> 0. randomly select a master build machine from the pool, let's call it
>> MASTER
>> 1. MASTER:  checkout source on any machine
>> 2. MASTER:  tar up source
>> 3. MASTER:  copy source to other platform build machines
>> 4. EACH PLATFORM:  untar onto each of those machines
>> 5. MASTER:  delete tar file
>> 6. MASTER:  clean.all
>> 7. MASTER:  ivy dependencies (specifying proper conf setting so that All
>> platforms dependency artifacts are downloaded)
>> 8. MASTER:  perform java compile
>> 9. MASTER:  copy dependencies and resulting jars from java compile to
>> other platform build machines
>> 10: EACH PLATFORM:  perform native code build
>> 11: EACH PLATFORM:  perform unit testing
>> 12: EACH PLATFORM:  copy resulting artifacts from each platform machine to
>> master machine
>> 13: MASTER:  publish all platform artifacts at once
>>
>> By using a good automated build system, you can easily handle this multi
>> platform build workflow and the hand off of control from one node to
>> another.  Then the publishing ONLY happens if ALL platforms are successful.
>>  Therefore, I do not need the ability to publish a partial module.
>>
>> I am sure there are other ways to do this and there is probably debate as
>> to how efficient this is, but it works very well in a production
>> environment.  If this sounds like an advertisement for QuickBuild, I
>> apologize.  I do not work for them.  I am just a passionate happy customer.
>>
>> ---
>> Shawn Castrianni
>>
>> -----Original Message-----
>> From: Felix Drueke [mailto:fdrueke@orga-systems.com]
>> Sent: Wednesday, January 12, 2011 4:59 AM
>> To: ivy-user@ant.apache.org
>> Subject: Publishing C-module artifacts from different platforms
>>
>> Hi,
>>
>> I'd like to manage the dependencies of a set of C-modules with ivy.
>> Each of these modules needs to be compiled on different platforms (i.e.
>> Solaris, Linux, HP-UX and others).
>>
>> This requires that the same sources are compiled in separate workspaces
>> (on the different hosts).
>>
>> In a first attempt I setup one ivy.xml with a set of configurations - one
>> for
>> each platform on that I have to build&publish artifacts.
>>
>> Being unexperienced with Ivy I didnd't find a way to just publish the
>> artifact for the one configuration that I built in a workspace.
>> For example I built module XYZ on Solaris and of course I can only
>> publish the Solaris-artifact from that workspace. In another worlspace
>> I got the artifact for Linux and of course I can only publish that.
>>
>> How do you accomplish to publish just the artifacts for one particular
>> configuration?
>>
>> Thanks for any hint,
>> Felix
>>
>> The information included in this e-mail and any files transmitted with it
>> is strictly confidential and may be privileged or otherwise protected from
>> disclosure. If you are not the intended recipient, please notify the sender
>> immediately by e-mail and delete this e-mail as well as any attachment from
>> your system. If you are not the intended recipient you are not authorized to
>> use and/or copy this message and/or attachment and/or disclose the contents
>> to any other person.
>>
>> ----------------------------------------------------------------------
>> This e-mail, including any attached files, may contain confidential and
>> privileged information for the sole use of the intended recipient.  Any
>> review, use, distribution, or disclosure by others is strictly prohibited.
>>  If you are not the intended recipient (or authorized to receive information
>> for the intended recipient), please contact the sender by reply e-mail and
>> delete all copies of this message.
>>
>>
> The information included in this e-mail and any files transmitted with it
> is strictly confidential and may be privileged or otherwise protected from
> disclosure. If you are not the intended recipient, please notify the sender
> immediately by e-mail and delete this e-mail as well as any attachment from
> your system. If you are not the intended recipient you are not authorized to
> use and/or copy this message and/or attachment and/or disclose the contents
> to any other person.
>

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