On 5/17/21 3:32 PM, Francesco Chemolli wrote:
> On Mon, May 17, 2021 at 8:32 PM Alex Rousskov wrote:
>
> On 5/17/21 2:17 AM, Francesco Chemolli wrote:
> > $ make all push
>
> Does that "make push" command automatically switch Jenkins CI to using
> the new/pushed containers? Or is
On Mon, May 17, 2021 at 8:32 PM Alex Rousskov <
rouss...@measurement-factory.com> wrote:
> On 5/17/21 2:17 AM, Francesco Chemolli wrote:
>
> > Our Linux environments are docker containers on amd64, armv7l and arm64.
> > On a roughly monthly cadence, I pull from our dockerfiles repo
> > (https://gi
On 5/17/21 2:17 AM, Francesco Chemolli wrote:
> Our Linux environments are docker containers on amd64, armv7l and arm64.
> On a roughly monthly cadence, I pull from our dockerfiles repo
> (https://github.com/kinkie/dockerfiles) and
> $ make all push
Does that "make push" command automatically swi
On 5/16/21 10:19 PM, squ...@treenet.co.nz wrote:
> On 2021-05-17 11:56, Alex Rousskov wrote:
>> On 5/16/21 3:31 AM, Amos Jeffries wrote:
>>> On 4/05/21 2:29 am, Alex Rousskov wrote:
The principles I have proposed allow upgrades that do not violate key
invariants. For example, if a propose
>
>
> Adding new nodes with next distro release versions is a manual process
> not related to keeping existing nodes up to date (which is automated?).
>
Mostly.
Our Linux environments are docker containers on amd64, armv7l and arm64.
On a roughly monthly cadence, I pull from our dockerfiles repo (
On 2021-05-17 11:56, Alex Rousskov wrote:
On 5/16/21 3:31 AM, Amos Jeffries wrote:
On 4/05/21 2:29 am, Alex Rousskov wrote:
On 5/3/21 12:41 AM, Francesco Chemolli wrote:
- we want our QA environment to match what users will use. For this
reason, it is not sensible that we just stop upgrading o
On 5/16/21 3:31 AM, Amos Jeffries wrote:
> On 4/05/21 2:29 am, Alex Rousskov wrote:
>> On 5/3/21 12:41 AM, Francesco Chemolli wrote:
>>> - we want our QA environment to match what users will use. For this
>>> reason, it is not sensible that we just stop upgrading our QA nodes,
>>
>> I see flaws in
On 4/05/21 2:29 am, Alex Rousskov wrote:
On 5/3/21 12:41 AM, Francesco Chemolli wrote:
- we want our QA environment to match what users will use. For this
reason, it is not sensible that we just stop upgrading our QA nodes,
I see flaws in reasoning, but I do agree with the conclusion -- yes, w
On 5/3/21 12:41 AM, Francesco Chemolli wrote:
> - we want our QA environment to match what users will use. For this
> reason, it is not sensible that we just stop upgrading our QA nodes,
I see flaws in reasoning, but I do agree with the conclusion -- yes, we
should upgrade QA nodes. Nobody has pr
On Wed, Apr 28, 2021 at 11:34 PM Alex Rousskov <
rouss...@measurement-factory.com> wrote:
> On 4/28/21 5:12 PM, Amos Jeffries wrote:
> > I'm not sure why this is so controversial still. We have already been
> > over these and have a policy from last time:
>
> Apparently, the recollections of what
On 4/28/21 5:12 PM, Amos Jeffries wrote:
> I'm not sure why this is so controversial still. We have already been
> over these and have a policy from last time:
Apparently, the recollections of what was agreed upon, if anything,
during that "last time" differ. If you can provide a pointer to that
"
I'm not sure why this is so controversial still. We have already been over these and have a policy from last time: * dev PR submissions use the volatile 5-pr-test, after test approval by anyone in QA. Check against unstable OS nodes, as many as possible. Kinkie adds/removes from that set as upgrade
On 4/28/21 1:45 AM, Francesco Chemolli wrote:
> I'm moving here the discussion from PR #806 about what strategy to
> have for CI tests, looking for an agreement.
> We have 3 classes of tests ni our CI farm
> (https://build.squid-cache.org/)
> - PR staging tests, triggered by commit hooks on Gi
Hi all,
I'm moving here the discussion from PR #806 about what strategy to have
for CI tests, looking for an agreement.
We have 3 classes of tests ni our CI farm (https://build.squid-cache.org/)
- PR staging tests, triggered by commit hooks on GitHub (possibly with
human approval)
the job is
14 matches
Mail list logo
