ekaterinadimitrova2 commented on PR #1953:
URL: https://github.com/apache/cassandra/pull/1953#issuecomment-1293704027
`OK, I updated the midres patch` I will take a look soon.
` For what it's worth, the README doesn't discuss what's in the patches at
all, or what the valus should be for various runs.`
What values ---> well, when we apply the patch we see what were the values
(same as in code patching) and we need to ensure when we add new jobs the old
jobs are not changed or affected and the new additions are as we want them.
I'd say in this case for the new job we agreed to match the values that were
assigned to the dtests(those values are assigned in time through testing, there
Is no direct matrix), that is how I compared that in MIDRES file something is
wrong and we do not have the values we wanted to have.Another way to make a
check is by looking at the executor assigned to our job, the resources in
MIDRES and in that executor should match. Maybe we need to say that patch is
nothing else than a regular patch, not something circle ci specific?
About the executor - well, this is circle ci terminology, I do not think we
should copy paste from the CircleCI docs in our readme. A new executor is added
to raise the resources to a level not applicable for LOWRES and HIGHRES. I
think the main issue for new comers is that having Readme they might not go to
CircleCI docs themselves and miss how things in CircleCI itself work. (That is
what I also did when I started, the people who created the initial setup with
generate.sh were not active anymore on the project :( )I do not want to add
links to docs in the readme as links change with versions and also they can get
broken. Maybe what we can do is to say "For information on executors please
check CircleCI documentation" or refer to this section or something else (but
by name, not link) https://circleci.com/docs/reusing-config/
`Looking at git blame ( :) ) I can see you've done a lot of work on this, so
you're much more familiar with this than I am, but I think we need to be
careful about confusing familiarity for clarity.`
I do not mean to argue and I totally agree about familiarity, especially in
the Cassandra world where CI is no exception for complexity considering how
many test suites, config options, etc we have. I am with you here. What I
wanted to point out is that patch is a patch no matter whether it is config
file or Java code. We need to verify the result of that patch. Clarity - I
think we just need to realize that Cassandra works with other tools, frameworks
and libraries that have their own documentation. It takes time to get
acquainted with everything and make the connections. It is its own process we
all go through. But we cannot and we should not rely on a customer specific
readme to cover how the actual tool works in detail IMHO. Again, I suggest we
add a point on top of the readme - "below information is cassandra specific
usage of CircleCI, you might want to read through the CircleCI documentation if
you are not familiar with the tool before moving forward." or something similar
.
My concern is even when we further improve and automate things, there will
be always corner cases and breakages and new suites and specifics so operating
one of our primary tools as a black box without taking the time to learn it how
it works is not sustainable. Personal opinion. Also, CircleCI as a product
itself evolves so we might want to follow up on new opportunities that we can
take advantage of.
I will review and post update in the next few hours. Thank you for the quick
fix :-) I think this one job is a good first exercise and then adding others,
being similar will be completely different experience. Thank you for your
efforts
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
