[Anthill-pro] RE: Propagating properties to dependencies
Alexandre Borgia
alexandre.borgia at ubisoft.com
Wed Jul 30 11:12:54 CDT 2008
Hi Emerson,
Yes the method I describe is on the dependency workflow. But you are right if they are mandatory properties I suppose they must be set before the workflow starts. On my side the properties I propagate are also "mandatory" properties but the flag is not set because of this problem. Our dependent workflows are seldom triggered manually anyway so it's not really an issue.
- Alexandre Borgia
-----Message d'origine-----
De : anthill-pro-bounces at lists.urbancode.com [mailto:anthill-pro-bounces at lists.urbancode.com] De la part de emerson cargnin
Envoyé : 30 juillet 2008 11:07
À : AnthillPro user and support list.; support at urbancode.com
Objet : Re: [Anthill-pro] RE: Propagating properties to dependencies
O believe it's on the dependency, right?
It happens that the workflow complains the variables are not set even
before starting the workflow, as the variables are required...
How did you do it then? I'm starting to see the only way is messing up
the agent selector script.
Urbancode guys is it possible to get some input from you?? It would be
so much easier if we had a checkbos on the dependency "cascade
properties".
thanks
emerson
On 30/07/2008, emerson cargnin <echofloripa.yell at gmail.com> wrote:
> Alexandre, is this done in the first job of the dependency workflow or
> on the dependent?
>
> On 27/07/2008, Alexandre Borgia <alexandre.borgia at ubisoft.com> wrote:
> > We have to do something similar here as well, but instead of putting the script in the Agent Filter it is an "eval script" step that is performed when needed in the first job of the workflow. This may be a way to leave the Agent Filter script alone.
> >
> > I agree it would be nice to have a built-in feature that takes care of this.
> >
> > - Alexandre Borgia
> >
> > -----Original Message-----
> > From: anthill-pro-bounces at lists.urbancode.com on behalf of emerson cargnin
> > Sent: Sun 27/07/2008 13:14
> > To: AnthillPro user and support list.
> > Subject: Re: [Anthill-pro] RE: Propagating properties to dependencies
> >
> > Hi Henning
> >
> > Thanks very much for the tip.
> > Although I still think this should be done internally in anthill. My
> > agent selctor script is quite complicated already, and I woud prefer
> > to not make it even more complicated : )
> >
> > any word from urbancode ont his?
> >
> > thanks
> > emerson
> >
> > On 26/07/2008, henning.behrens at uniserv.com <henning.behrens at uniserv.com> wrote:
> > > Hi,
> > >
> > > in this special case I could provide a solution. (Force Build of dependencies, each spefified by a special tag in the father workflow).
> > >
> > > We solved this problem using a naming convention. The main idea is, to look from the br of the dependency wf to the br of the father wf, to read the desired wf-property and store it as a BuildRequest property in the Build Request of the dependency wf.
> > >
> > > It sounds a little bit complicated, but works fine.
> > >
> > > Let F be the father wf and D the dependency wf F needs to accomplish his work.
> > >
> > > Define wf-property in F denoted with: D_SVN_TAG
> > > Define the dependency to D in F as "pull_build" and "cascade force"
> > > Define a wf-property SOURCE_URL_REL in F and D.
> > > In the Source Config Source URL property of F and D write: ${property:SOURCE_URL_REL}
> > > ( For the dependency wf D this will be set from the agent selector script provided below. If D_SVN_TAG in F is empty, the Default Value of SOURCE_URL_REL of wf D will be used, because a BR-property will not be set in this case).
> > >
> > > Now you will have to use an agent selector script, looking as follows:
> > > (We define an agent property named: anthill3/tpi on each agent, so that each agent is
> > > uniquely defined. E.g. anthill3/tpi="solaris8_sparc_32")
> > > The below agent selector script, ensures additionally the execution of father and dependency wf on the same machine).
> > >
> > > ==============================
> > > package de.uniserv.util.anthill;
> > >
> > > import org.apache.log4j.Logger;
> > >
> > > import com.urbancode.anthill3.domain.agent.Agent;
> > > import com.urbancode.anthill3.domain.buildlife.BuildLife;
> > > import com.urbancode.anthill3.domain.buildrequest.BuildRequest;
> > > import com.urbancode.anthill3.domain.buildrequest.RequestSourceEnum;
> > > import com.urbancode.anthill3.domain.persistent.Persistent;
> > > import com.urbancode.anthill3.domain.profile.BuildProfile;
> > > import com.urbancode.anthill3.domain.profile.Dependency;
> > > import com.urbancode.anthill3.domain.script.agentfilter.criteria.VariableEqualsCriteria;
> > > import com.urbancode.anthill3.runtime.scripting.helpers.BuildLifeLookup;
> > > import com.urbancode.anthill3.runtime.scripting.helpers.BuildRequestLookup;
> > > import com.urbancode.anthill3.runtime.scripting.helpers.ChangeLogHelper;
> > > import com.urbancode.anthill3.runtime.scripting.helpers.PropertyLookup;
> > > import com.urbancode.anthill3.persistence.UnitOfWork;
> > > import com.urbancode.vcsdriver3.ChangeLog;
> > > import com.urbancode.vcsdriver3.ChangeSet;
> > > import com.urbancode.vcsdriver3.XmlParsingException;
> > >
> > > UnitOfWork uow = UnitOfWork.getCurrent ();
> > >
> > > public class UniservPropertyEqualsAgentVar extends VariableEqualsCriteria {
> > >
> > > final static Logger log = Logger.getLogger("ReportScript");
> > >
> > > String propertyname;
> > >
> > > public UniservPropertyEqualsAgentVar(String propertyname, String varName) {
> > > super(varName);
> > > this.propertyname = propertyname;
> > > }
> > >
> > >
> > > public Agent[] filter(Agent[] agents) {
> > > String platform;
> > >
> > > // Get my current Build Request
> > > BuildRequest myCurrentBuildRequest = BuildRequestLookup.getCurrent();
> > >
> > > // -----------------------------------
> > > // Get BuildProfile
> > > BuildProfile myBuildProfile = myCurrentBuildRequest.getBuildProfile();
> > > // Get DependencyArray
> > > Dependency[] myDepArray = myBuildProfile.getDependencyArray();
> > >
> > > // -----------------------------------
> > > // If I am a dependency BuildRequest, look at my fathers wf-properties and look
> > > // if he has a SVN_TAG_<my_project_name> property for me
> > > if (myCurrentBuildRequest.getRequestSource() == RequestSourceEnum.DEPENDENCY) {
> > > Persistent parentRequest = myCurrentBuildRequest.getRequester();
> > > BuildRequest myParentBr = null;
> > > if (parentRequest instanceof BuildRequest) {
> > > myParentBr = (BuildRequest) parentRequest;
> > > } else {
> > > throw new IllegalArgumentException("Not a Buildrequest!");
> > > }
> > > // Get Property SVN_TAG_<myProjectName> from father, if exists
> > > String currProjectName = myCurrentBuildRequest.getProject()
> > > .getName().toUpperCase();
> > > String mySvnTag = myParentBr.getProperty("SVN_TAG_" + currProjectName);
> > > // If not empty, set BuildRequest Property
> > > if ((mySvnTag != null) && (mySvnTag.length() > 0)) {
> > > // Here the magic happens ;-)
> > > myCurrentBuildRequest.setProperty("SOURCE_URL_REL", "tags/"
> > > + mySvnTag);
> > > }
> > >
> > > platform = myParentBr.getProperty("TPI");
> > >
> > > // store target platform information of my father at my own BR
> > > myCurrentBuildRequest.setProperty("TPI",platform);
> > >
> > > // Iteration über alle Dependencies des Vater-Objektes
> > > Dependency[] parentDepArray = myParentBr.getBuildProfile().getDependencyArray();
> > >
> > > this.setValue(platform);
> > > return super.filter(agents);
> > > } else { // weiter wie bisher (unveraendert)
> > > // Hier liegt ein WF vor, der Dependencies hat, setzen der
> > > // erforderlichen
> > > // Stamp Patterns
> > >
> > > platform = PropertyLookup.get(propertyname);
> > > this.setValue(platform);
> > > return super.filter(agents);
> > > }
> > > }
> > > }
> > >
> > > return Where.is(new UniservPropertyEqualsAgentVar("TPI", "anthill3/tpi"));
> > >
> > > uow.commit();
> > >
> > > ===============================
> > >
> > > I hope, the above code snippit still works, because I removed a lot of things we do additionally in this place.
> > > Please, let me know how this works for you.
> > >
> > > Regards
> > > Henning
> > >
> > > -----Original Message-----
> > >
> > > Message: 2
> > > Date: Fri, 25 Jul 2008 14:12:43 +0100
> > > From: "emerson cargnin" <echofloripa.yell at gmail.com>
> > > Subject: [Anthill-pro] Propagating properties to dependencies
> > > To: support at urbancode.com, "AnthillPro user and support list."
> > > <anthill-pro at lists.urbancode.com>
> > > Message-ID:
> > > <806d3a1f0807250612p46846eeak3c856dbdefefea17 at mail.gmail.com>
> > > Content-Type: text/plain; charset=ISO-8859-1
> > >
> > > Hi
> > >
> > > I had requested this a while ago, but now the lack of this has become a major concern for us.
> > >
> > > I have some projects that have other dependencies projects.
> > > I use two primary workflows basically, a build from trunk (for dev and
> > > CI) and a build from tag . For the CI one, its dependency forces a build, and it will use the default values of the properties, which get the build from the trunk.
> > >
> > > For the buildfrom the tag, I can force a build, because the dependency would need to know the tag it's building from. What I did was to not force the build and use the latest successful build from "build from the tag" workflow of the dependency workflow, but in this case people need always to remember to run the dependency workflow before.
> > > Sometimes not running
> > >
> > > It would be much easier if the properties were propagated to the dependencies... Please please can we have it? :)
> > >
> > > Regards
> > > Emerson
> > > _______________________________________________
> > > Anthill-pro mailing list
> > > Anthill-pro at lists.urbancode.com
> > > http://lists.urbancode.com/mailman/listinfo/anthill-pro
> > >
> > _______________________________________________
> > Anthill-pro mailing list
> > Anthill-pro at lists.urbancode.com
> > http://lists.urbancode.com/mailman/listinfo/anthill-pro
> >
> >
> > _______________________________________________
> > Anthill-pro mailing list
> > Anthill-pro at lists.urbancode.com
> > http://lists.urbancode.com/mailman/listinfo/anthill-pro
> >
> >
> >
>
_______________________________________________
Anthill-pro mailing list
Anthill-pro at lists.urbancode.com
http://lists.urbancode.com/mailman/listinfo/anthill-pro
More information about the Anthill-pro
mailing list