[hibernate-dev] Keeping CI from being confusing.

Steve Ebersole steve at hibernate.org
Sat Dec 16 14:03:36 EST 2017


Perhaps I am just dense here, but I still have no idea what you are
expecting me to use as the label for my ORM jobs


On Sat, Dec 16, 2017 at 12:53 PM Sanne Grinovero <sanne at hibernate.org>
wrote:

> On 16 December 2017 at 16:44, Steve Ebersole <steve at hibernate.org> wrote:
> > For the main ORM job I see someone changed the label to "AWS&&Slave",
> which
> > is obviously different from the "Slave" label you recommended.
> Basically at
> > this point I am completely lost as to what to use for these labels.
>
> We used to have machines on either OS1 or AWS (two different clouds).
> ORM jobs used to require AWS as only the nodes on AWS have enough
> memory.
> Today using "AWS" is fine but not required as all our nodes are on AWS.
>
> >
> > Since I did not add this "AWS&&Slave" I am going to leave it alone.  For
> the
> > other ORM jobs, I do see many have the "OS1" label.  I can fix those to
> > "Slave".  But I have to ask... if "Slave" is the more appropriate value
> for
> > the vast majority of builds, can't that just be the default?  What if we
> > leave off the label?  As you say, labels are supposed to indicate that
> the
> > job "requires such capabilities" as in the capabilities implied by that
> > label.  But if a job has no such requirement, why is it a requirement to
> add
> > any label?
>
> The machine identified as "Master" actually runs the ci.hibernate.org
> main service and various other important services (e.g.
> in.relation.to) so we'd like to keep any non necessary load from it;
> also it doesn't have all the databases installed which many jobs might
> need.
> The only reason it's listed as a node capable to run a CI job at all
> is that it's useful to keep it available for some specific jobs,
> specifically we had problems with urgent changes to the website
> getting stuck in a long and busy build queue; the decision was to
> allow website publication jobs to be executed directly by the master
> node.
> Essentially, it helps with priorities.
>
> >
> > On Tue, Dec 12, 2017 at 6:31 AM Sanne Grinovero <sanne at hibernate.org>
> wrote:
> >>
> >> I see many jobs are still explicitly configured to request a build on
> >> slaves tagged as "OS1".
> >>
> >> Please get rid of that: we have no longer any slave running on OS1,
> >> some of the new slaves use the "OS1" label to allow a smooth migration
> >> - but it's a lie and it's been a long time since we removed OS1.
> >>
> >> I will need to eventually cleanup such things, as it's getting messy
> >> and confusing.
> >>
> >> Labels are expected to be used to tag specific slaves to have specific
> >> capabilities, so that some jobs can flag they require such
> >> capabilities.
> >>
> >> Typically the only label you need is "Slave" as we don't want most
> >> jobs to run on the master node.
> >>
> >> An example of a valid label is "HANA" for the job running integration
> >> tests on the HANA database; for obvious reasons this job needs to be
> >> run on the only slave actually having HANA running.
> >>
> >> While at it, if you installed any Jenkins plugin which you no longer
> >> need please remove it.
> >>
> >> General reminder: there's no dedicated team to keep CI or
> >> infrastructure running efficiently, we're all responsible so try to
> >> dedicate it some 20 minutes every month making sure your jobs are
> >> still necessary and configurations are up to date.
> >> For more extensive operations ask Davide or myself and we'll see to
> help.
> >>
> >> Thanks,
> >> Sanne
> >> _______________________________________________
> >> hibernate-dev mailing list
> >> hibernate-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>


More information about the hibernate-dev mailing list