now its all ok, i rerun your pr here :
https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_RunAll_IgniteTests24Java8=pull%2F7906%2Fhead=buildTypeStatusDiv
>Hi Ivan,
>
>let me first apologize for the question, sure they are stupid and I am
>missing something obvious but
Hi Ivan,
let me first apologize for the question, sure they are stupid and I am
missing something obvious but I do not get what.
I forked ignite there https://github.com/hostettler/ignite
Then I comitted everything in my fork and then I create a pull request at
Hi Steve,
No need to apologize. You can always ask help from the community.
P.S. Sincerely Ignite development workflow is not so simple =)
2020-07-08 8:18 GMT+03:00, Zhenya Stanilovsky :
>
>
> now its all ok, i rerun your pr here
> :
>
Nikolay,
Can you, please, write down your version of requirements so we can reach a
> consensus on that and therefore move to the discussion of the
> implementation?
I guess that Max's requirements quite similar to your requirements:
1. The framework should support deployment on
Nikolay,
There is *NO *intention to ignore code style violations and do merge PRs
into the master branch without fixing them.
Let's assume that I want to implement a dirty fix of a bug, check a
reproducer from the user list, etc.
And I do not have the intention to merge that into the master
Slava,
Why the auto-formatting procedure cannot be used for any PR you'd like
to run on TC? Even more, you can remove all the rules from checkstyle
XML config and do all you want in the PR branch.
On Tue, 7 Jul 2020 at 12:17, Вячеслав Коптилин wrote:
>
> Hi Nikolay,
>
> > Why do you need to Run
All checks just force rules we agreed on.
> Why this check is so important? Why do you think it is more important than
> all other tasks/tests?
Because any code style violations should be fixed before the merge.
Therefore after the fix, you must rerun TC.
This means that running heavy suites
Hi Nikolay,
> Why do you need to Run All on TC resources for this task?
For instance, it may be a race that cannot be reproduced locally on my own
hardware.
(By the way, even though if I just want to start Cache1 suite, the
Code-Style check executes anyway).
> If we don’t want to follow the code
Hi Maxim,
> Why the auto-formatting procedure cannot be used for any PR you'd like to
run on TC?
> Even more, you can remove all the rules from checkstyle XML config and do
all you want in the PR branch
Yes, I can enable auto-formatting, which should be checked anyway, I can
edit pom.xml every
底限 created IGNITE-13223:
---
Summary: empty Batch throw an Exception
Key: IGNITE-13223
URL: https://issues.apache.org/jira/browse/IGNITE-13223
Project: Ignite
Issue Type: Bug
Components: jdbc
Folks,
In addition to answers above, I think TC.Bot must comment PR with
violated checkstyle rules and references to source code if the build
has failed. This may be more convenient for contributors from my point
of view.
On Tue, 7 Jul 2020 at 11:50, Ivan Pavlukhin wrote:
>
> Folks,
>
> This
Dmitry Frolov created IGNITE-13225:
--
Summary: Add the possibility to export data in OpenCensus only
from defined metrics
Key: IGNITE-13225
URL: https://issues.apache.org/jira/browse/IGNITE-13225
Hello Maxim,
> Why do you think that splitting the checkstyle build is better option
than fixing code style issues reporting by the checkstyle plugin?
Why do you think that Ilya talks that code style errors should not be fixed?
It looks weird to me that we do not even start the tests if check
Slava.
All contributors should follow our code style during their contribution.
For now, we have an automatic PR check that is integrated to the GitHub
interface.
I don’t see any issue here.
All open-source project that I know, uses the same approach.
Anyway, If some of the experienced
Dmitry Frolov created IGNITE-13224:
--
Summary: Add metrics to OpenCensus exporter
Key: IGNITE-13224
URL: https://issues.apache.org/jira/browse/IGNITE-13224
Project: Ignite
Issue Type:
Hello Nikolay,
> Because any code style violations should be fixed before the merge.
> Therefore after the fix, you must rerun TC.
> This means that running heavy suites when code style is violated is a
waste of the resources.
This makes sense, however, to be honest, I don't see that our team
Folks,
This discussion reoccurs from month to month. Last one I remember is
[1]. It sounds useful to pin a decision to our coding guidelines. What
do you think?
[1]
http://apache-ignite-developers.2346864.n4.nabble.com/DISCUSSION-Separate-code-sanity-check-and-build-task-td47003.html
> Let's assume that I want to implement a dirty fix of a bug, check a
> reproducer from the user list, etc.
Why do you need to Run All on TC resources for this task?
> I do not want to waste my time fixing all code style violations.
I assume that you have the Ignite project locally because
> Why can't this check be done in parallel with other tasks?
Because when we contribute code to Ignite we must follow code style.
> I am not against the code-style check at all.
Yes, you are :) But it’s ok
> I just want to get some freedom for dev branches only, if it is possible of
>
Hello Alex,
> In my opinion checkstyle rules definitely should be checked as early as
possible and by default should fail Ignite build.
Well, perhaps I am wrong. Ok.
> But for exceptional cases (which was mentioned by Slava), can we add some
> "Run custom build" parameter on TC to be able to
Steve i place some comments in ticket, still have no response.
>
>
>--- Forwarded message ---
>From: " steve.hostett...@gmail.com " < steve.hostett...@gmail.com >
>To: dev@ignite.apache.org
>Cc:
>Subject: Re: Re[4]: IGNITE-6499 Compact NULL fields
>Date: Fri, 12 Jun 2020 16:15:37
Hi!
Do you have any updates about this issue? What types of implementations
have you chosen (in-place, offline, or in the background)? I know that we
want to add a partition defragmentation function, we can add a hole to
integrate the re-encryption scheme. Could you update your IEP with your
Guys,
In my opinion checkstyle rules definitely should be checked as early as
possible and by default should fail Ignite build.
But for exceptional cases (which was mentioned by Slava), can we add some
"Run custom build" parameter on TC to be able to exclude "checkstyle"
profile from "~Build
> > I am not against the code-style check at all.
> Yes, you are :) But it’s ok
No, I am not :)
> You can take a look at the commits that introduced checks and how many
files were touched.
I really appreciate this, Nikolay.
Thanks,
S.
вт, 7 июл. 2020 г. в 13:04, Nikolay Izhikov :
> > Why
Hi Denis,
What do you think about some improvements in @IgniteAsyncCallback regarding
usability? What if we add a number of threads parameter in @IgniteAsyncCallback?
Best regards,
Roman
-Original Message-
From: Denis Magda
Sent: Friday, June 26, 2020 7:38 PM
To: dev
Subject: Re:
Guys,
Can somebody help with creating scheduled build triggers for nightly "Run
All" on TC for "ignite-2.9" branch?
Also, I found that we still have a nightly "Run All" for "ignite-2.8"
branch [1]. Do we still need it? Or just forgot to remove it after release?
[1] :
Hello!
I have changed the schedule condition so ignite-2.9 will be run instead.
Please check if it works tomorrow.
Regards,
--
Ilya Kasnacheev
вт, 7 июл. 2020 г. в 16:42, Alex Plehanov :
> Guys,
>
> Can somebody help with creating scheduled build triggers for nightly "Run
> All" on TC for
Ilya,
Perhaps I expressed my thoughts vaguely. I have nothing against
discussion. I suggest to pin and describe a decision if/when it is
made.
2020-07-07 17:10 GMT+03:00, Ilya Kasnacheev :
> Hello!
>
> Ivan, unfortunately, I can't see any formal decision being taken. All I see
> in the
Pavel Tupitsyn created IGNITE-13226:
---
Summary: .NET: Thin Client Compute leaks ClientNotificationHandler
instances
Key: IGNITE-13226
URL: https://issues.apache.org/jira/browse/IGNITE-13226
Project:
Hello!
Ivan, unfortunately, I can't see any formal decision being taken. All I see
in the referenced thread is people who are unhappy with obligatory code
style checking as a prerequisite to running tests.
Did we hold a formal vote on this issue? Did we even hold an informal vote?
It may turn up
Hello, Maksim.
For implementation, I chose so-called "in place background
re-encryption" design.
The first step is to rotate the key for writing data, it only works on
the active cluster, at the moment..
The second step is re-encryption (to remove previous encryption key).
If node was restarted
Hello,
Look at the ticket and the only comment I can see is creating a branch on
git in the main repo and not in my fork. I do not have the right to create a
branch in the main repository. Am i missing something?
Sorry I probably misread the document but I though that I should fork the
repo and
Hello,
can I have the rights to create a branch on the github mirror. Thanks
--
Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/
request it, check for example [1]
also you need to run [2] tests.
[1]
http://apache-ignite-developers.2346864.n4.nabble.com/Phani-Introduction-td47788.html
[2] https://mtcga.gridgain.com
>Hello,
>
>Look at the ticket and the only comment I can see is creating a branch on
>git in the main
hi、
Can I assign the following jira permissions to me
https://issues.apache.org/jira/browse/IGNITE-13223
Hi Steve,
Usually we use GitHub forks to create branches and submit pull
requests. Check [1] for more details.
[1]
https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute#HowtoContribute-Workflow
2020-07-07 19:19 GMT+03:00, steve.hostett...@gmail.com
:
> Hello,
>
> can I have the
Amelchev Nikita created IGNITE-13227:
Summary: AssertionError on getting cache size from the mbean on
the inactive cluster
Key: IGNITE-13227
URL: https://issues.apache.org/jira/browse/IGNITE-13227
37 matches
Mail list logo
