Re: [hibernate-dev] Keeping CI from being confusing.

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(a)hibernate.org&gt; wrote: > On 16 December 2017 at 16:44, Steve Ebersole <steve(a)hibernate.org&gt; 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(a)hibernate.org&gt; > 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(a)lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev