Re: Enabling Continuous Delivery / automated release process for Gradle project

2021-12-16 Thread 'Jesse Glick' via Jenkins Developers
On Thu, Dec 16, 2021 at 10:44 AM 'jn...@cloudbees.com' via Jenkins Developers wrote: > you are still tagging the commit "[maven-release-plugin] prepare release > project-a.bcd" the only difference is that these commits never appear on > the mainline branch (master) > Yes, this is possible.

Re: Enabling Continuous Delivery / automated release process for Gradle project

2021-12-16 Thread 'jn...@cloudbees.com' via Jenkins Developers
>> Using MRP as I described would not confuse any tool >Depends on the tool. The problem would be that a source checkout at the commit/tag would, if loaded as a project rather than a deployed artifact, have a version different from the artifact. (Also true in JEP-229 components by default,

Re: Enabling Continuous Delivery / automated release process for Gradle project

2021-12-14 Thread 'Jesse Glick' via Jenkins Developers
On Tue, Dec 14, 2021 at 6:04 PM James Nord wrote: > the flatten plugin confuses tools Which? I think we have ironed out any problems as lots of components have picked up JEP-305. Even seems to work fine on BOMs; the last things I am hesitant

Re: Enabling Continuous Delivery / automated release process for Gradle project

2021-12-14 Thread James Nord
But my point is the flatten plugin confuses tools and is awkward for many. Using MRP as I described would not confuse any tool as it would reqrite a pom as happens today. I'm also confused now as you are using MRP which the referenced comment is about. On Tuesday, 14 December 2021 at

Re: Enabling Continuous Delivery / automated release process for Gradle project

2021-12-14 Thread 'Jesse Glick' via Jenkins Developers
On Tue, Dec 14, 2021 at 9:53 AM 'jn...@cloudbees.com' via Jenkins Developers wrote: > there is possibility of something part way between the current CD flow (no > junk pushes) and m-r-p > As mentioned previously

Re: Enabling Continuous Delivery / automated release process for Gradle project

2021-12-14 Thread Jean-Marc Meessen
Hello, It is possible to configure it so that the release process is triggered manually (accumulating several changes) instead of an automatic trigger. The documentation (or sample code) shows what is the section to "comment out". /- Jmm Le mar. 14 déc. 2021 à 15:53, 'jn...@cloudbees.com' via

Re: Enabling Continuous Delivery / automated release process for Gradle project

2021-12-14 Thread 'jn...@cloudbees.com' via Jenkins Developers
there is possibility of something part way between the current CD flow (no junk pushes) and m-r-p. m-r-p does not have to just take the current version and remove snapshot and increment the last digit, nor does it need to push the commits back (just the tag) (which I believe are your main

Re: Enabling Continuous Delivery / automated release process for Gradle project

2021-12-02 Thread 'Jesse Glick' via Jenkins Developers
On Wednesday, November 17, 2021 at 8:29:07 AM UTC-5 Jesse Glick wrote: > One thing which should be possible in principle, but which I have not had > reason to try, is to use MRP with the backend part. > Implemented in https://github.com/jenkins-infra/jenkins-maven-cd-action/pull/14. Not as

Re: Enabling Continuous Delivery / automated release process for Gradle project

2021-11-17 Thread 'Jesse Glick' via Jenkins Developers
On Wed, Nov 17, 2021 at 4:05 AM Tim Jacomb wrote: > That's assuming that the gradle plugin supports incrementals which I don't > know if it does. > It does not, and the whole concept is rather specific to Maven. Stepping back, there are basically two sides to JEP-229: a backend patch to the

Re: Enabling Continuous Delivery / automated release process for Gradle project

2021-11-17 Thread Tim Jacomb
I don't think it will have been done yet because the GitHub actions only support maven. There's not many projects using gradle so I guess you're the first to look at it. The action wouldn't need much work to support it, Probably just a flag defaulted to maven and then a change in this script: