Dear Ignite Community!
I propose for discussion the conception of using two TeamCity servers with
a roadmap.
https://ci.ignite.apache.org/
https://ci2.ignite.apache.org/
Storing project settings.
Servers synchronize configurations between themselves using the version
control-storing DSL (reposito
Hi!
There is a pretty popular project NullAway [1] that checks code of a
project in compile-time for possible NPE. AFAIK, it works only with the
"@Nullable" annotation. I think we can try to add this check to Ignite2 and
3.
But I wonder, whether smbd already tried to introduce this check? If not,
Hello Petr,
Can you please assist with configuring the Release Teamcity suite that
has been changed for 2.x a month ago? These changes haven't been
discussed on the dev-list, so I'm not familiar with them.
I've faced several issues:
- the default role for Apache Ignite 2.x (Release) suite is `Age
Could you please add links to builds that are malfunctioning?
As much as I see here [1] and here [2] — the release build changed to comply
with 2.12 changes that are not merged to 2.11.1
[1]
https://ci.ignite.apache.org/buildConfiguration/Releases_ApacheIgniteMain_ReleaseBuild/6329822
[2]
http
+1 for option No. 2.
On Fri, 17 Dec 2021 at 12:10, Maksim Timonin
wrote:
> Hi!
>
> There is a pretty popular project NullAway [1] that checks code of a
> project in compile-time for possible NPE. AFAIK, it works only with the
> "@Nullable" annotation. I think we can try to add this check to Igni
Permissions updated.
> On 17 Dec 2021, at 13:09, Petr Ivanov wrote:
>
> Could you please add links to builds that are malfunctioning?
> As much as I see here [1] and here [2] — the release build changed to comply
> with 2.12 changes that are not merged to 2.11.1
>
>
> [1]
> https://ci.ignit
Concerning Too many requests error, I see the following problem:
Your request has been rate limited, as we have detected excessive usage from
your IP or net block:
15.575 SECONDS OF TIME SPENT OVER 120 SECONDS, MAX ALLOWED IS 15.
Rate-limits are automatic and reset every two minutes.
If you feel
Petr,
Thank you.
Yes, I've added changes related to the new release build actions
(IGNITE-15678, IGNITE-15677). The ignite-2.12 branch seems to be
working fine, however, at the ignite-2.11.1 the error with "too many
requests" appears from time to time. Here is an example of such a
build [1].
[1
Witaliy,
> repository is created
> only in the master branch
I strongly suggest avoiding a separate repository for project settings.
Let's store them in https://github.com/apache/ignite
*1. We should be able to test code changes together with CI/CD changes.*
*2. We should be able to have differe
TeamCity DSL just does not work as you wish it should.
Changes from branches are not visible: you cannot run new suite added in branch
because it just won't be visible from UI because project UI is rendered from
default branch only),
and at least snapshot dependencies are taken from default bra
I've dropped GitBox in favour of GitHub — the build [1] has started.
[1]
https://ci.ignite.apache.org/buildConfiguration/Releases_ApacheIgniteMain_ReleaseBuild/6329862
> On 17 Dec 2021, at 13:24, Maxim Muzafarov wrote:
>
> Petr,
>
> Thank you.
>
> Yes, I've added changes related to the new
Petr,
> you cannot run new suite added in branch because it just won't be visible
from UI
That's unfortunate.
However, a more important scenario is "make changes to the existing project
in a branch", which is supported, as I understand [1]
[1]
https://www.jetbrains.com/help/teamcity/storing-proj
Thanks for the update!
On Thu, Dec 16, 2021 at 9:07 PM Виталий Осилов
wrote:
> Hi!
> TeamCity server https://ci2.ignite.apache.org/ will be unavailable on
> Friday 17.12 from 22:00 MSK to 00:00 MSK
> Works will be done to synchronize the TeamCity configuration
> https://ci2.ignite.apache.org/ wi
Pavel,
If you are referring to this paragraph
• If you are using TeamCity feature branches, you can define a branch
specification when creating a project from URL (Git only) or in the VCS root
used for versioned settings. TeamCity will run a build in a branch using the
settings from t
Petr,
> why should I edit code in Apache Ignite 2.x repo to introduce new changes
in Apache Ignite 3.x build settings
I thought we can store 3.x settings in 3.x repo and so on.
Looks like it does not work as I hoped it would.
Thanks for your answers.
On Fri, Dec 17, 2021 at 2:35 PM Petr Ivanov
Maksim, thank you for the suggestion.
I've never used NullAway, but after having a quick look I think it might be
an overkill, since it is a plugin for the ErrorProne, which is a separate
tool. I recall some efforts of introducing ErrorProne to Ignite 3 and they
were not successful. But again, I d
Petr,
> I strongly suggest avoiding a separate repository for project settings.
> Let's store them in https://github.com/apache/ignite
Sounds good, but we must avoid dozens of additional commits in this case.
Each commit should be properly formalized and related to the issue.
We may create a spec
The release candidate for the 2.11.1 version is ready.
I have uploaded a release candidate to:
https://dist.apache.org/repos/dist/dev/ignite/2.11.1-rc1/
https://dist.apache.org/repos/dist/dev/ignite/packages_2.11.1-rc1/
The following staging can be used for testing:
https://repository.apache.org
+1
Checked binary packages, .NET examples and NuGets.
On Fri, Dec 17, 2021 at 3:20 PM Maxim Muzafarov wrote:
> The release candidate for the 2.11.1 version is ready.
>
>
> I have uploaded a release candidate to:
> https://dist.apache.org/repos/dist/dev/ignite/2.11.1-rc1/
> https://dist.apache.o
Hello, Slava.
I am planning the following timeline:
Voting Date: December 20, 2021
Release Date: December 27, 2021
чт, 16 дек. 2021 г. в 11:52, Вячеслав Коптилин :
>
> Hello Nikita,
>
> > I have cherry-picked the issue [1] to the 2.12. It updates the log4j
> version to 2.16.
> Thanks a lot!
>
>
>I thought we can store 3.x settings in 3.x repo and so on.
It's not a good idea to use different repositories.
Ignite also has many different modules, but all are situated in the same
project.
If we use different repositories, we can get a situation when a template
from another project will be
We CAN store build settings per project — ignite, ignite-3, ignite-extensions
and so on.
However, ROOT project will still be not under VCS and some major settings like
VCS roots, Clean-Up rules, custom step runners and so much more will stay out
of Git-based sync.
And in order to achieve full se
Using Kotlin we no longer need templates, as any build configuration (as
object) can be heavily customised, parametrised and reused as many times as you
like.
However, if we are going to separate build settings per project, in me
experience — we may need some kind of lib with common customisati
Separate JIRA project will ruin the concept of introducing changes for both
code and build settings in single branch of single project.
> On 17 Dec 2021, at 15:14, Anton Vinogradov wrote:
>
> Petr,
>
>> I strongly suggest avoiding a separate repository for project settings.
>> Let's store the
Hi Nikita,
The proposed timeline looks great. Thank you!
Slava.
пт, 17 дек. 2021 г. в 15:32, Nikita Amelchev :
> Hello, Slava.
>
> I am planning the following timeline:
>
> Voting Date: December 20, 2021
> Release Date: December 27, 2021
>
> чт, 16 дек. 2021 г. в 11:52, Вячеслав Коптилин :
> >
Hello Maxim,
Honestly, I don't quite understand why ODBC improvement is included in the
release.
It seems to me, we have an agreement that the scope of the 2.11.1 release
will be limited by log4j issues.
Thanks,
S.
пт, 17 дек. 2021 г. в 15:20, Maxim Muzafarov :
> The release candidate for the
Slava,
The release build scripts have been changed [1]. It's not possible to
build 2.11 from scratch. Since we are going the fastest route (and
safest I suppose) it's better to cherry-pick these changes to the
release rather than changing something on TC.
[1] https://issues.apache.org/jira/browse
Slava, unfortunately, after some works that improves C++ bulding process,
now it is impossible to build old releases.
пт, 17 дек. 2021 г. в 16:28, Вячеслав Коптилин :
> Hello Maxim,
>
> Honestly, I don't quite understand why ODBC improvement is included in the
> release.
> It seems to me, we have
Petr,
> However, ROOT project will still be not under VCS and some major settings
like VCS roots, Clean-Up rules, custom step runners and so much more will
stay out of Git-based sync.
VCS roots are project-related and should not be stored somewhere outside
the project.
Also, having different roots
Hi Maxim, Ivan,
Thank you for the clarification. So, I have no objections.
+1
Thanks,
S.
пт, 17 дек. 2021 г. в 16:35, Ivan Daschinsky :
> Slava, unfortunately, after some works that improves C++ bulding process,
> now it is impossible to build old releases.
>
> пт, 17 дек. 2021 г. в 16:28, Вяч
Hi,
Thanks for your comment. I rebuilt the documentation and pushed all
changes. Now all should be fine.
On Fri, Dec 17, 2021 at 1:47 PM 18624049226 <18624049...@163.com> wrote:
> Hi,
>
> It seems that all documents are unpublished version 2.12 documents?
>
> For example, the following documents
There was a reason to store VCS settings in ROOT project — minimising git polls
which often caused 'too many connections' error, because each new VCS is
separate instance even if it is the same as in the other project.
Duplicating VCSs will reduce git performance.
Also — if we are going to have
+1 (binding)
-
Denis
On Fri, Dec 17, 2021 at 7:20 AM Maxim Muzafarov wrote:
> The release candidate for the 2.11.1 version is ready.
>
>
> I have uploaded a release candidate to:
> https://dist.apache.org/repos/dist/dev/ignite/2.11.1-rc1/
> https://dist.apache.org/repos/dist/dev/ignite/package
+1
On Fri, Dec 17, 2021 at 6:01 AM Denis Magda wrote:
> +1 (binding)
>
> -
> Denis
>
>
> On Fri, Dec 17, 2021 at 7:20 AM Maxim Muzafarov wrote:
>
> > The release candidate for the 2.11.1 version is ready.
> >
> >
> > I have uploaded a release candidate to:
> > https://dist.apache.org/repos/dist
Hi,
While option #2 looks very appealing it seems not bulletproof
reliable, someone can occasionally miss @Nullable annotation. Option
#3 seems more practical too me, as missed @NotNull annotations cannot
do much harm.
Also I am thinking about using nullable parameters in general. Perhaps
we can
35 matches
Mail list logo
