On Mon, Jun 1, 2020 at 3:40 PM Thomas Heigl <tho...@umschalt.com> wrote:

> >
> > 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


+1


>
>
> 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