In theory, you can use Jenkins pipelines scripts in your projects, but I
haven't tested that out yet. It's the system we're using at my work.
On 12 June 2017 at 14:25, Dominik Psenner wrote:
> I envision to automate the build and publishing process. At work we are
> migrating to git and along wi
I envision to automate the build and publishing process. At work we are
migrating to git and along with that we are going to set up our (insane)
build process with gitlab runners executed by virtualbox executors. See
https://docs.gitlab.com/runner/ and
https://docs.gitlab.com/ee/ci/yaml/README.html
We're doing the same in log4j right now as well. I'd love to figure out a
more fluid way of doing this eventually.
On 12 June 2017 at 10:16, Stefan Bodewig wrote:
> On 2017-06-12, Matt Sicker wrote:
>
> > That's an interesting use case. Are you using gitpubsub instead of
> > svnpubsub for the si
On 2017-06-12, Matt Sicker wrote:
> That's an interesting use case. Are you using gitpubsub instead of
> svnpubsub for the site then?
"mvn site" plus manual copy over to svn plus the logging site's
svnpubsub. Yes, it is painful :-)
Stefan
That's an interesting use case. Are you using gitpubsub instead of
svnpubsub for the site then?
On 10 June 2017 at 12:41, Dominik Psenner wrote:
> We have also the site versioned in the same repository. Updates to the
> website do not necessarily synchronize well with the library releases. So
>
We have also the site versioned in the same repository. Updates to the
website do not necessarily synchronize well with the library releases. So
this is a good example where the master branch is useful to track published
website patches. In a wider sense, updates to the website are one kind of
hot
Agreed. Whenever I've used git-flow in the past, the only reason we had a
develop and master branch was so that it was simpler to write hotfixes
against master later on. We'd delete our release branches after they were
tagged and merged to master&develop, so the only ways to find what's in
producti
I'm unlikely to do development on Log4jnet but I like having 'master'
instead of 'develop' for the reason Julius stated.
Gary
On Fri, Jun 9, 2017 at 9:07 AM, Julius Davies
wrote:
> Hi,
>
> The 'master' branch in the gitflow model is pointless (that state is
> already tracked with the 'release/*
Hi,
The 'master' branch in the gitflow model is pointless (that state is
already tracked with the 'release/*' branches). I say ditch the 'master'
branch and make 'develop' the default branch (e.g., the one that a fresh
"git clone" automatically checks out).
And rebase the short lived feature br
Hi,
On 2017-05-23 08:49, Stefan Bodewig wrote:
Please ensure github tracks develop as the default branch when the vote passes.
I just filed an issue on INFRA to make this happen. This is the ticket
for it:
https://issues.apache.org/jira/browse/INFRA-14316
Cheers,
Dominik
On 2017-05-22, Dominik Psenner wrote:
> This is a vote to introduce gitflow on the log4net subproject. gitflow
> would mean that we make use of the following named branches:
> * master
> Marks stable milestones and is moves on with a release.
> * develop
> Development of the next milesto
This is a vote to introduce gitflow on the log4net subproject. gitflow
would mean that we make use of the following named branches:
* master
Marks stable milestones and is moves on with a release.
* develop
Development of the next milestone should happen here.
* feature/featurename
12 matches
Mail list logo
