Re: New Committers - community
Il gio 3 gen 2019, 22:37 Tibor Digana ha scritto: > Why the build cannot be triggered on GitHub or PR? > It's only a URL. > You are right, github gives special refs which represents the branch of the forked repo, like pull/123/head. The problem is that our CI is configured for gitbox and not for github, so we don't have those special refs Enrico If you see the frequency of PRs in Surefire, 1 or 2 PRs/month, this should > not be a problem since the Windows build takes 1.5 hour and Linux 1 hour. > Taking JDK 7 and 11, and one Maven version (3.5) is usually enough on Git > branches and should be fine for PRs as well. > > On Thu, Jan 3, 2019 at 10:19 PM Stephen Connolly < > stephen.alan.conno...@gmail.com> wrote: > > > On Thu 3 Jan 2019 at 20:52, Tibor Digana wrote: > > > > > I already lost the point of this thread. > > > Still the disk space problem on Windows executors in ASF Jenkins? > > > If it's this issue, then why the workspace is not investigated directly > > on > > > the system with remote access? > > > Jenkins is very good tool and I do not want to use Travis but Travis is > > one > > > step after finding the root cause. > > > > > > We’re not going to be able to use Travis for Surefire (unless we have a > > “fast” suite of tests) > > > > That doesn’t mean we cannot use Travis for the 90 other repos we have in > > order to get test results of PRs from non-committers. > > > > > > > T > > > > > > On Thu, Jan 3, 2019 at 8:39 PM Stephen Connolly < > > > stephen.alan.conno...@gmail.com> wrote: > > > > > > > On Thu 3 Jan 2019 at 18:03, Enrico Olivelli > > wrote: > > > > > > > > > Il gio 3 gen 2019, 17:38 Mickael Istria ha > > > scritto: > > > > > > > > > > > Hi, > > > > > > > > > > > > I think this discussion is diverging into "trying TravisCI for > some > > > > > > plugins" and is loosing focus on the initial question of how to > > > improve > > > > > the > > > > > > build+test flow to get faster feedback as a contributor or as a > > > > reviewer. > > > > > > > > > > > > Travis will get the build+test flow faster for non-committers. > > > > > > > > > > > > > > Can the GitHub PR builder plugin be enabled on Maven Core ? > > > > > > > > > > > > No, it’s not compatible with how we build, as currently we only build > > > from > > > > gitbox not from GitHub so there is no link for Jenkins to see > > > > > > > > > > > > Committers > > > > > > would be allowed to trigger a test with a single comment once > they > > > > > checked > > > > > > it doesn't cause a security flaw. > > > > > > > > > > > > > > > > It turns out that it is not simple as it could seem because we have > > > > custom > > > > > Jenkins plugins to scan all the repos and have a common > > configuration, > > > so > > > > > in order to achieve such goal we need to enhance that plugin, > please > > > > > Stephen correct me if I am wrong. > > > > > > > > > > > > Yep I need to enhance the plugin a little... just trying to clear > stuff > > > off > > > > my plate > > > > > > > > > > > > > Travis jumped on this train because it is easy to enable and it is > > very > > > > > widespread, and it leaves security problems out of ASF infra. > > > > > But a check with Travis won't ever cover all jobs we are actually > > > > starting > > > > > per-branch. > > > > > It can be a good compromise to start, but if we have resources to > > > improve > > > > > current integration this will be the best choice for the mid term. > > > > > > > > > > Enrico > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > > -- > > > > > > > > > > > > > > > -- Enrico Olivelli > > > > > > > > > -- > > > > Sent from my phone > > > > > > > > > -- > > Sent from my phone > > > -- -- Enrico Olivelli
Re: New Committers - community
I am doing #2. This means I create a GitBox branch or I run it on my own PC. Not a problem at all because usually the contributor does not complete it and I have to add some test or clarify the change in documentation. Sometime I have to rework the PR even if the idea was good, and I have to squash the commits. So I am quite patient while triggering the CI via a branch but I cannot represent the colleagues of course. Running PRs automatically would be really a good idea. T On Thu, Jan 3, 2019 at 10:45 PM Stephen Connolly < stephen.alan.conno...@gmail.com> wrote: > On Thu 3 Jan 2019 at 21:37, Tibor Digana wrote: > > > Why the build cannot be triggered on GitHub or PR? > > It's only a URL. > > If you see the frequency of PRs in Surefire, 1 or 2 PRs/month, this > should > > not be a problem since the Windows build takes 1.5 hour and Linux 1 hour. > > Taking JDK 7 and 11, and one Maven version (3.5) is usually enough on Git > > branches and should be fine for PRs as well. > > > 1. The current branch source only discovers branches in gitbox, it doesn’t > discover PRs on GitHub. > > 2. PRs on GitHub can have “untrusted” code, which shouldn’t be run within > the ASF hardware without review by a committer. > > #1 can be solved by me enhancing the Jenkins plugin we use > > #2 either means asking committers to trigger builds after reviewing (which > is a manual step and manual steps get forgotten) > > So instead we get Travis to do a first round CI for the PRs on GitHub. Then > we can still have #1 and #2 as final pre-merge confirmation... but Travis > gives the contributor immediate feedback on their contribution and that > helps grow the community. > > > > > > On Thu, Jan 3, 2019 at 10:19 PM Stephen Connolly < > > stephen.alan.conno...@gmail.com> wrote: > > > > > On Thu 3 Jan 2019 at 20:52, Tibor Digana > wrote: > > > > > > > I already lost the point of this thread. > > > > Still the disk space problem on Windows executors in ASF Jenkins? > > > > If it's this issue, then why the workspace is not investigated > directly > > > on > > > > the system with remote access? > > > > Jenkins is very good tool and I do not want to use Travis but Travis > is > > > one > > > > step after finding the root cause. > > > > > > > > > We’re not going to be able to use Travis for Surefire (unless we have a > > > “fast” suite of tests) > > > > > > That doesn’t mean we cannot use Travis for the 90 other repos we have > in > > > order to get test results of PRs from non-committers. > > > > > > > > > > T > > > > > > > > On Thu, Jan 3, 2019 at 8:39 PM Stephen Connolly < > > > > stephen.alan.conno...@gmail.com> wrote: > > > > > > > > > On Thu 3 Jan 2019 at 18:03, Enrico Olivelli > > > wrote: > > > > > > > > > > > Il gio 3 gen 2019, 17:38 Mickael Istria ha > > > > scritto: > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > I think this discussion is diverging into "trying TravisCI for > > some > > > > > > > plugins" and is loosing focus on the initial question of how to > > > > improve > > > > > > the > > > > > > > build+test flow to get faster feedback as a contributor or as a > > > > > reviewer. > > > > > > > > > > > > > > > Travis will get the build+test flow faster for non-committers. > > > > > > > > > > > > > > > > > Can the GitHub PR builder plugin be enabled on Maven Core ? > > > > > > > > > > > > > > > No, it’s not compatible with how we build, as currently we only > build > > > > from > > > > > gitbox not from GitHub so there is no link for Jenkins to see > > > > > > > > > > > > > > > Committers > > > > > > > would be allowed to trigger a test with a single comment once > > they > > > > > > checked > > > > > > > it doesn't cause a security flaw. > > > > > > > > > > > > > > > > > > > It turns out that it is not simple as it could seem because we > have > > > > > custom > > > > > > Jenkins plugins to scan all the repos and have a common > > > configuration, > > > > so > > > > > > in order to achieve such goal we need to enhance that plugin, > > please > > > > > > Stephen correct me if I am wrong. > > > > > > > > > > > > > > > Yep I need to enhance the plugin a little... just trying to clear > > stuff > > > > off > > > > > my plate > > > > > > > > > > > > > > > > Travis jumped on this train because it is easy to enable and it > is > > > very > > > > > > widespread, and it leaves security problems out of ASF infra. > > > > > > But a check with Travis won't ever cover all jobs we are actually > > > > > starting > > > > > > per-branch. > > > > > > It can be a good compromise to start, but if we have resources to > > > > improve > > > > > > current integration this will be the best choice for the mid > term. > > > > > > > > > > > > Enrico > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > > > > -- > > > > > > > > > > > > > > > > > > -- Enrico Olivelli > > > > > > > > > > > -- > > > > > Sent from my phone > > > > > > > > > > > > -- > > > Sent from my phone > > > > > > -- > Sent from my phone >
Re: New Committers - community
On Thu 3 Jan 2019 at 21:37, Tibor Digana wrote: > Why the build cannot be triggered on GitHub or PR? > It's only a URL. > If you see the frequency of PRs in Surefire, 1 or 2 PRs/month, this should > not be a problem since the Windows build takes 1.5 hour and Linux 1 hour. > Taking JDK 7 and 11, and one Maven version (3.5) is usually enough on Git > branches and should be fine for PRs as well. 1. The current branch source only discovers branches in gitbox, it doesn’t discover PRs on GitHub. 2. PRs on GitHub can have “untrusted” code, which shouldn’t be run within the ASF hardware without review by a committer. #1 can be solved by me enhancing the Jenkins plugin we use #2 either means asking committers to trigger builds after reviewing (which is a manual step and manual steps get forgotten) So instead we get Travis to do a first round CI for the PRs on GitHub. Then we can still have #1 and #2 as final pre-merge confirmation... but Travis gives the contributor immediate feedback on their contribution and that helps grow the community. > > On Thu, Jan 3, 2019 at 10:19 PM Stephen Connolly < > stephen.alan.conno...@gmail.com> wrote: > > > On Thu 3 Jan 2019 at 20:52, Tibor Digana wrote: > > > > > I already lost the point of this thread. > > > Still the disk space problem on Windows executors in ASF Jenkins? > > > If it's this issue, then why the workspace is not investigated directly > > on > > > the system with remote access? > > > Jenkins is very good tool and I do not want to use Travis but Travis is > > one > > > step after finding the root cause. > > > > > > We’re not going to be able to use Travis for Surefire (unless we have a > > “fast” suite of tests) > > > > That doesn’t mean we cannot use Travis for the 90 other repos we have in > > order to get test results of PRs from non-committers. > > > > > > > T > > > > > > On Thu, Jan 3, 2019 at 8:39 PM Stephen Connolly < > > > stephen.alan.conno...@gmail.com> wrote: > > > > > > > On Thu 3 Jan 2019 at 18:03, Enrico Olivelli > > wrote: > > > > > > > > > Il gio 3 gen 2019, 17:38 Mickael Istria ha > > > scritto: > > > > > > > > > > > Hi, > > > > > > > > > > > > I think this discussion is diverging into "trying TravisCI for > some > > > > > > plugins" and is loosing focus on the initial question of how to > > > improve > > > > > the > > > > > > build+test flow to get faster feedback as a contributor or as a > > > > reviewer. > > > > > > > > > > > > Travis will get the build+test flow faster for non-committers. > > > > > > > > > > > > > > Can the GitHub PR builder plugin be enabled on Maven Core ? > > > > > > > > > > > > No, it’s not compatible with how we build, as currently we only build > > > from > > > > gitbox not from GitHub so there is no link for Jenkins to see > > > > > > > > > > > > Committers > > > > > > would be allowed to trigger a test with a single comment once > they > > > > > checked > > > > > > it doesn't cause a security flaw. > > > > > > > > > > > > > > > > It turns out that it is not simple as it could seem because we have > > > > custom > > > > > Jenkins plugins to scan all the repos and have a common > > configuration, > > > so > > > > > in order to achieve such goal we need to enhance that plugin, > please > > > > > Stephen correct me if I am wrong. > > > > > > > > > > > > Yep I need to enhance the plugin a little... just trying to clear > stuff > > > off > > > > my plate > > > > > > > > > > > > > Travis jumped on this train because it is easy to enable and it is > > very > > > > > widespread, and it leaves security problems out of ASF infra. > > > > > But a check with Travis won't ever cover all jobs we are actually > > > > starting > > > > > per-branch. > > > > > It can be a good compromise to start, but if we have resources to > > > improve > > > > > current integration this will be the best choice for the mid term. > > > > > > > > > > Enrico > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > > -- > > > > > > > > > > > > > > > -- Enrico Olivelli > > > > > > > > > -- > > > > Sent from my phone > > > > > > > > > -- > > Sent from my phone > > > -- Sent from my phone
Re: New Committers - community
Why the build cannot be triggered on GitHub or PR? It's only a URL. If you see the frequency of PRs in Surefire, 1 or 2 PRs/month, this should not be a problem since the Windows build takes 1.5 hour and Linux 1 hour. Taking JDK 7 and 11, and one Maven version (3.5) is usually enough on Git branches and should be fine for PRs as well. On Thu, Jan 3, 2019 at 10:19 PM Stephen Connolly < stephen.alan.conno...@gmail.com> wrote: > On Thu 3 Jan 2019 at 20:52, Tibor Digana wrote: > > > I already lost the point of this thread. > > Still the disk space problem on Windows executors in ASF Jenkins? > > If it's this issue, then why the workspace is not investigated directly > on > > the system with remote access? > > Jenkins is very good tool and I do not want to use Travis but Travis is > one > > step after finding the root cause. > > > We’re not going to be able to use Travis for Surefire (unless we have a > “fast” suite of tests) > > That doesn’t mean we cannot use Travis for the 90 other repos we have in > order to get test results of PRs from non-committers. > > > > T > > > > On Thu, Jan 3, 2019 at 8:39 PM Stephen Connolly < > > stephen.alan.conno...@gmail.com> wrote: > > > > > On Thu 3 Jan 2019 at 18:03, Enrico Olivelli > wrote: > > > > > > > Il gio 3 gen 2019, 17:38 Mickael Istria ha > > scritto: > > > > > > > > > Hi, > > > > > > > > > > I think this discussion is diverging into "trying TravisCI for some > > > > > plugins" and is loosing focus on the initial question of how to > > improve > > > > the > > > > > build+test flow to get faster feedback as a contributor or as a > > > reviewer. > > > > > > > > > Travis will get the build+test flow faster for non-committers. > > > > > > > > > > > Can the GitHub PR builder plugin be enabled on Maven Core ? > > > > > > > > > No, it’s not compatible with how we build, as currently we only build > > from > > > gitbox not from GitHub so there is no link for Jenkins to see > > > > > > > > > Committers > > > > > would be allowed to trigger a test with a single comment once they > > > > checked > > > > > it doesn't cause a security flaw. > > > > > > > > > > > > > It turns out that it is not simple as it could seem because we have > > > custom > > > > Jenkins plugins to scan all the repos and have a common > configuration, > > so > > > > in order to achieve such goal we need to enhance that plugin, please > > > > Stephen correct me if I am wrong. > > > > > > > > > Yep I need to enhance the plugin a little... just trying to clear stuff > > off > > > my plate > > > > > > > > > > Travis jumped on this train because it is easy to enable and it is > very > > > > widespread, and it leaves security problems out of ASF infra. > > > > But a check with Travis won't ever cover all jobs we are actually > > > starting > > > > per-branch. > > > > It can be a good compromise to start, but if we have resources to > > improve > > > > current integration this will be the best choice for the mid term. > > > > > > > > Enrico > > > > > > > > > > > > > > Cheers, > > > > > > > > > -- > > > > > > > > > > > > -- Enrico Olivelli > > > > > > > -- > > > Sent from my phone > > > > > > -- > Sent from my phone >
Re: New Committers - community
On Thu 3 Jan 2019 at 20:52, Tibor Digana wrote: > I already lost the point of this thread. > Still the disk space problem on Windows executors in ASF Jenkins? > If it's this issue, then why the workspace is not investigated directly on > the system with remote access? > Jenkins is very good tool and I do not want to use Travis but Travis is one > step after finding the root cause. We’re not going to be able to use Travis for Surefire (unless we have a “fast” suite of tests) That doesn’t mean we cannot use Travis for the 90 other repos we have in order to get test results of PRs from non-committers. > T > > On Thu, Jan 3, 2019 at 8:39 PM Stephen Connolly < > stephen.alan.conno...@gmail.com> wrote: > > > On Thu 3 Jan 2019 at 18:03, Enrico Olivelli wrote: > > > > > Il gio 3 gen 2019, 17:38 Mickael Istria ha > scritto: > > > > > > > Hi, > > > > > > > > I think this discussion is diverging into "trying TravisCI for some > > > > plugins" and is loosing focus on the initial question of how to > improve > > > the > > > > build+test flow to get faster feedback as a contributor or as a > > reviewer. > > > > > > Travis will get the build+test flow faster for non-committers. > > > > > > > > Can the GitHub PR builder plugin be enabled on Maven Core ? > > > > > > No, it’s not compatible with how we build, as currently we only build > from > > gitbox not from GitHub so there is no link for Jenkins to see > > > > > > Committers > > > > would be allowed to trigger a test with a single comment once they > > > checked > > > > it doesn't cause a security flaw. > > > > > > > > > > It turns out that it is not simple as it could seem because we have > > custom > > > Jenkins plugins to scan all the repos and have a common configuration, > so > > > in order to achieve such goal we need to enhance that plugin, please > > > Stephen correct me if I am wrong. > > > > > > Yep I need to enhance the plugin a little... just trying to clear stuff > off > > my plate > > > > > > > Travis jumped on this train because it is easy to enable and it is very > > > widespread, and it leaves security problems out of ASF infra. > > > But a check with Travis won't ever cover all jobs we are actually > > starting > > > per-branch. > > > It can be a good compromise to start, but if we have resources to > improve > > > current integration this will be the best choice for the mid term. > > > > > > Enrico > > > > > > > > > > > Cheers, > > > > > > > -- > > > > > > > > > -- Enrico Olivelli > > > > > -- > > Sent from my phone > > > -- Sent from my phone
Re: [VOTE] Release Maven Wagon version 3.3.1
+1 tested with maven-3.6.1-SNAPSHOT plus wagon-3.3.1 against a large build. -D On Thu, Jan 3, 2019 at 5:28 AM Michael Osipov wrote: > Hi, > > We solved 6 issues: > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318122=12344772 > > There are still a couple of issues left in JIRA: > > https://issues.apache.org/jira/issues/?jql=project%20%3D%20WAGON%20AND%20resolution%20%3D%20Unresolved > > Staging repo: > https://repository.apache.org/content/repositories/maven-1483/ > > https://repository.apache.org/content/repositories/maven-1483/org/apache/maven/wagon/wagon/3.3.1/wagon-3.3.1-source-release.zip > > Source release checksum(s): > wagon-3.3.1-source-release.zip > sha512: > > 398d8d028cbaff4fdc6380a105af8c2111915931db9c46f404e96c6de82b713995f3842ffd32b61e1a0b6c4249973af69a6256c160babf2d3acf7cff5417a649 > > Staging site: > https://maven.apache.org/wagon-archives/wagon-LATEST/ > > Guide to testing staged releases: > http://maven.apache.org/guides/development/guide-testing-releases.html > > Vote open for 72 hours. > > [ ] +1 > [ ] +0 > [ ] -1 > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
Re: New Committers - community
Il gio 3 gen 2019, 21:52 Tibor Digana ha scritto: > I already lost the point of this thread. > We are trying to figure out how to give better support for new contributions, the first point is to give feedback as soon as possible (an automatic build is the top) Enrico Still the disk space problem on Windows executors in ASF Jenkins? > If it's this issue, then why the workspace is not investigated directly on > the system with remote access? > Jenkins is very good tool and I do not want to use Travis but Travis is one > step after finding the root cause. > T > > On Thu, Jan 3, 2019 at 8:39 PM Stephen Connolly < > stephen.alan.conno...@gmail.com> wrote: > > > On Thu 3 Jan 2019 at 18:03, Enrico Olivelli wrote: > > > > > Il gio 3 gen 2019, 17:38 Mickael Istria ha > scritto: > > > > > > > Hi, > > > > > > > > I think this discussion is diverging into "trying TravisCI for some > > > > plugins" and is loosing focus on the initial question of how to > improve > > > the > > > > build+test flow to get faster feedback as a contributor or as a > > reviewer. > > > > > > Travis will get the build+test flow faster for non-committers. > > > > > > > > Can the GitHub PR builder plugin be enabled on Maven Core ? > > > > > > No, it’s not compatible with how we build, as currently we only build > from > > gitbox not from GitHub so there is no link for Jenkins to see > > > > > > Committers > > > > would be allowed to trigger a test with a single comment once they > > > checked > > > > it doesn't cause a security flaw. > > > > > > > > > > It turns out that it is not simple as it could seem because we have > > custom > > > Jenkins plugins to scan all the repos and have a common configuration, > so > > > in order to achieve such goal we need to enhance that plugin, please > > > Stephen correct me if I am wrong. > > > > > > Yep I need to enhance the plugin a little... just trying to clear stuff > off > > my plate > > > > > > > Travis jumped on this train because it is easy to enable and it is very > > > widespread, and it leaves security problems out of ASF infra. > > > But a check with Travis won't ever cover all jobs we are actually > > starting > > > per-branch. > > > It can be a good compromise to start, but if we have resources to > improve > > > current integration this will be the best choice for the mid term. > > > > > > Enrico > > > > > > > > > > > Cheers, > > > > > > > -- > > > > > > > > > -- Enrico Olivelli > > > > > -- > > Sent from my phone > > > -- -- Enrico Olivelli
Re: New Committers - community
I already lost the point of this thread. Still the disk space problem on Windows executors in ASF Jenkins? If it's this issue, then why the workspace is not investigated directly on the system with remote access? Jenkins is very good tool and I do not want to use Travis but Travis is one step after finding the root cause. T On Thu, Jan 3, 2019 at 8:39 PM Stephen Connolly < stephen.alan.conno...@gmail.com> wrote: > On Thu 3 Jan 2019 at 18:03, Enrico Olivelli wrote: > > > Il gio 3 gen 2019, 17:38 Mickael Istria ha scritto: > > > > > Hi, > > > > > > I think this discussion is diverging into "trying TravisCI for some > > > plugins" and is loosing focus on the initial question of how to improve > > the > > > build+test flow to get faster feedback as a contributor or as a > reviewer. > > > Travis will get the build+test flow faster for non-committers. > > > > > Can the GitHub PR builder plugin be enabled on Maven Core ? > > > No, it’s not compatible with how we build, as currently we only build from > gitbox not from GitHub so there is no link for Jenkins to see > > > Committers > > > would be allowed to trigger a test with a single comment once they > > checked > > > it doesn't cause a security flaw. > > > > > > > It turns out that it is not simple as it could seem because we have > custom > > Jenkins plugins to scan all the repos and have a common configuration, so > > in order to achieve such goal we need to enhance that plugin, please > > Stephen correct me if I am wrong. > > > Yep I need to enhance the plugin a little... just trying to clear stuff off > my plate > > > > Travis jumped on this train because it is easy to enable and it is very > > widespread, and it leaves security problems out of ASF infra. > > But a check with Travis won't ever cover all jobs we are actually > starting > > per-branch. > > It can be a good compromise to start, but if we have resources to improve > > current integration this will be the best choice for the mid term. > > > > Enrico > > > > > > > > Cheers, > > > > > -- > > > > > > -- Enrico Olivelli > > > -- > Sent from my phone >
Re: New Committers - community
On Thu 3 Jan 2019 at 18:03, Enrico Olivelli wrote: > Il gio 3 gen 2019, 17:38 Mickael Istria ha scritto: > > > Hi, > > > > I think this discussion is diverging into "trying TravisCI for some > > plugins" and is loosing focus on the initial question of how to improve > the > > build+test flow to get faster feedback as a contributor or as a reviewer. Travis will get the build+test flow faster for non-committers. > > Can the GitHub PR builder plugin be enabled on Maven Core ? No, it’s not compatible with how we build, as currently we only build from gitbox not from GitHub so there is no link for Jenkins to see Committers > > would be allowed to trigger a test with a single comment once they > checked > > it doesn't cause a security flaw. > > > > It turns out that it is not simple as it could seem because we have custom > Jenkins plugins to scan all the repos and have a common configuration, so > in order to achieve such goal we need to enhance that plugin, please > Stephen correct me if I am wrong. Yep I need to enhance the plugin a little... just trying to clear stuff off my plate > Travis jumped on this train because it is easy to enable and it is very > widespread, and it leaves security problems out of ASF infra. > But a check with Travis won't ever cover all jobs we are actually starting > per-branch. > It can be a good compromise to start, but if we have resources to improve > current integration this will be the best choice for the mid term. > > Enrico > > > > > Cheers, > > > -- > > > -- Enrico Olivelli > -- Sent from my phone
Re: New Committers - community
Il gio 3 gen 2019, 17:38 Mickael Istria ha scritto: > Hi, > > I think this discussion is diverging into "trying TravisCI for some > plugins" and is loosing focus on the initial question of how to improve the > build+test flow to get faster feedback as a contributor or as a reviewer. > Can the GitHub PR builder plugin be enabled on Maven Core ? Committers > would be allowed to trigger a test with a single comment once they checked > it doesn't cause a security flaw. > It turns out that it is not simple as it could seem because we have custom Jenkins plugins to scan all the repos and have a common configuration, so in order to achieve such goal we need to enhance that plugin, please Stephen correct me if I am wrong. Travis jumped on this train because it is easy to enable and it is very widespread, and it leaves security problems out of ASF infra. But a check with Travis won't ever cover all jobs we are actually starting per-branch. It can be a good compromise to start, but if we have resources to improve current integration this will be the best choice for the mid term. Enrico > > Cheers, > -- -- Enrico Olivelli
Re: New Committers - community
Hi, I think this discussion is diverging into "trying TravisCI for some plugins" and is loosing focus on the initial question of how to improve the build+test flow to get faster feedback as a contributor or as a reviewer. Can the GitHub PR builder plugin be enabled on Maven Core ? Committers would be allowed to trigger a test with a single comment once they checked it doesn't cause a security flaw. Cheers,
[VOTE] Release Maven Wagon version 3.3.1
Hi, We solved 6 issues: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318122=12344772 There are still a couple of issues left in JIRA: https://issues.apache.org/jira/issues/?jql=project%20%3D%20WAGON%20AND%20resolution%20%3D%20Unresolved Staging repo: https://repository.apache.org/content/repositories/maven-1483/ https://repository.apache.org/content/repositories/maven-1483/org/apache/maven/wagon/wagon/3.3.1/wagon-3.3.1-source-release.zip Source release checksum(s): wagon-3.3.1-source-release.zip sha512: 398d8d028cbaff4fdc6380a105af8c2111915931db9c46f404e96c6de82b713995f3842ffd32b61e1a0b6c4249973af69a6256c160babf2d3acf7cff5417a649 Staging site: https://maven.apache.org/wagon-archives/wagon-LATEST/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[CANCELED] [VOTE] Release Maven Wagon version 3.3.0
I am canceling the vote because the change introduced in WAGON-537 triggered a bug in JSch which we need to work around: WAGON-544. I will recall the vote with a fixed version. Michael - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: New Committers - community
Il gio 3 gen 2019, 08:19 Hervé BOUTEMY ha scritto: > yes, on our 100 Git repos [1], 90% should be easy to run on any CI with > minimum configuration and resources > > then there is Maven core and complex plugins (like Surefire) which are not > the > same story > > if someone wants to test other toolings to show some useful feature we > don't > get in our current ASF Jenkins configuration [2], just start with some > examples of the base 90% and make a demo of something that would be useful > to > add to our configuration > I would like to try Maybe a brand new plugin like [3] scripting plugin can be a good candidate But we need a configuration from infra and I don't know if we need a formal vote or at least some PMC formal approval Enrico [3] https://github.com/apache/maven-scripting-plugin/pull/1 > Regards, > > Hervé > > [1] https://maven.apache.org/scm.html#Maven_Sources_Overview > > [2] https://github.com/apache/maven-jenkins-lib > > Le mercredi 2 janvier 2019, 15:38:12 CET Enrico Olivelli a écrit : > > Il giorno mer 2 gen 2019 alle ore 15:34 Vladimir Sitnikov > > > > ha scritto: > > > Enrico> For instance maven-surefire > > > integration tests take 2 hours. > > > In general I see Travis (free edition) does not offer many resources. > > > > > > Each Travis job is limited by 50 minutes, however one can split tests > into > > > multiple jobs, so it will run fine. > > > > I guess it won't be easy. > > Maven integration testing is very complex, it's Maven launching Maven > > itself. We will need to improve maven-invoker plugin, I don't know if > there > > is support for something like JUnit categories. > > We can run only "unit tests" and this will be a minimal "feedback" for > > the contributor. > > For simpler plugins, like "checkstyle", I think Travis would be a good > > choice, at least I would give it a try > > > > Enrico > > > > > Vladimir > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > > -- -- Enrico Olivelli
PR for archetype plugin: Groovy + Ivy Support
i've provided a PR [1] for ARCHETYPE-536 some time ago - it's really a small change, integration test is included. can it be added to the code base? thanks! stefan [1] https://github.com/apache/maven-archetype/pull/20 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
