>
> Now I checked the GitHub Actions docs (
> https://help.github.com/en/actions/reference/events-that-trigger-workflows
> )
> and added support for Pull Requests.
> Since we have .github/workflows only in master branch it won't trigger any
> builds for 8.x, 7.x, ... If we want this then we have to downport it.
>

It's working now, thanks Martin!

We should probably add caching for Maven dependencies. Fetching them every
time slows down the build quite a bit:

https://help.github.com/en/actions/language-and-framework-guides/building-and-testing-java-with-maven#caching-dependencies

Thomas

On Mon, Jun 1, 2020 at 1:35 PM Martin Grigorov <mgrigo...@apache.org> wrote:

> On Mon, Jun 1, 2020 at 1:10 PM Thomas Heigl <tho...@umschalt.com> wrote:
>
> > Thanks for the infos Andrea and Martin! I think that answers all my
> > questions.
> >
> > The official CI tool is BuildBot but since recently we also added GitHub
> > > Actions since it comes for free (i.e. any maintenance from us).
> > > At the moment it builds only master branch but we can remove this
> > > restriction and let it build all branches:
> > >
> > >
> >
> https://github.com/apache/wicket/blob/99cdfa5d6cd1f359c855af21595ca4aa5137b6e1/.github/workflows/maven.yml#L5-L6
> > > I think this will be useful for PRs!
> >
> >
> > @Martin: I just pushed to #436 but it did not trigger the CI build even
> > after you removed the branch filter. The reason might be that I created
> the
> > PR from my own fork. I'll switch to creating branches directly in the
> > Wicket repository for my next PR.
> >
>
> Now I checked the GitHub Actions docs (
> https://help.github.com/en/actions/reference/events-that-trigger-workflows
> )
> and added support for Pull Requests.
> Since we have .github/workflows only in master branch it won't trigger any
> builds for 8.x, 7.x, ... If we want this then we have to downport it.
>
>
> >
> > Best,
> >
> > Thomas
> >
> >
> >
> >
> > On Mon, Jun 1, 2020 at 10:41 AM Martin Grigorov <mgrigo...@apache.org>
> > wrote:
> >
> > > Hi,
> > >
> > > On Sun, May 31, 2020 at 2:17 PM Andrea Del Bene <an.delb...@gmail.com>
> > > wrote:
> > >
> > > > Hi Thomas!
> > > >
> > > > On 30/05/20 18:52, Thomas Heigl wrote:
> > > > > Hi all,
> > > > >
> > > > > Do we have any guidelines regarding the development workflow? E.g.
> > > > >
> > > > > - How many approvals do I need for merging a PR?
> > > > PR approvals on GitHub is a relatively new thing and there is no
> strict
> > > > rule about it. As empiric rule we try to get the approval from (at
> > > > least) a couple of other commiters. But it also depends on the
> > > > complexity of the PR, and for those who might have a bigger impact on
> > > > framework it's good to involve other people on the @dev list.
> > > >
> > >
> > > PRs are not mandatory.
> > > I create PR only when I am not really sure about the solution I am
> > > suggesting.
> > > Even if you push something directly without a PR we will review it and
> if
> > > we see something we will comment on it either in GitHub or on dev@.
> Once
> > > we
> > > agree on a better solution we may either push a new commit with an
> > > improvement or revert the old one.
> > >
> > >
> > > > > - Who manages the changelog? Should a changelog entry be part of
> > every
> > > > PR?
> > > > PR should come with a Jira issue to track them. The change log is
> > > > automatically generated during the release process using the 'Fix
> > > > Version' parameter of the issues. For example this is the current
> > change
> > > > log for for the upcoming 8.9.0 version
> > > >
> > > >
> > > >
> > >
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12348154&styleName=&projectId=12310561
> > > > > - How do we decide what PRs to backport to older versions?
> > > > This is usually asked in the @dev list, depending on the importance
> of
> > > > the PR (ex: is a fix or a new feature?) and its feasibility (ex: can
> be
> > > > easily / safely back-ported?)
> > > >
> > >
> > > If it is a new feature usually I commit it to the current stable branch
> > > (i.e. 8.x at the moment) and the next dev branch (9.x).
> > > If it is a fix then I also include the previous stable branch (7.x).
> > > If it is a security related fix then the also 6.x. Once we release
> 9.0.0
> > > then 7.x becomes the security maintenance branch.
> > >
> > >
> > > > >
> > > > > And are there CI builds for PRs? I would feel more confident
> clicking
> > > the
> > > > > merge button if there was a CI status check connected to GitHub
> (and
> > > > > possibly a Sonarqube check as well).
> > > > If I remember correctly GitHub should provide some kind of support
> for
> > > > PRs CI, but I never explored this feature, maybe Martin did something
> > > > about it.
> > > >
> > >
> > > The official CI tool is BuildBot but since recently we also added
> GitHub
> > > Actions since it comes for free (i.e. any maintenance from us).
> > > At the moment it builds only master branch but we can remove this
> > > restriction and let it build all branches:
> > >
> > >
> >
> https://github.com/apache/wicket/blob/99cdfa5d6cd1f359c855af21595ca4aa5137b6e1/.github/workflows/maven.yml#L5-L6
> > > I think this will be useful for PRs!
> > >
> > > Martin
> > >
> > >
> > > > >
> > > > > Thanks!
> > > > >
> > > > > Thomas
> > > > >
> > > > Your are welcome!
> > > >
> > >
> >
>

Reply via email to