Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Aug 05 08:58
    luisalves00 opened #226
  • Jul 30 00:17

    rpalcolea on main

    Upgrade to nebula plugin-plugin… (compare)

  • Jul 29 23:06

    rpalcolea on main

    plugin-plugin 16.3.0 (compare)

  • Jul 29 20:45

    rpalcolea on main

    Gradle 7.5 (compare)

  • Jul 28 20:26

    rpalcolea on main

    Gradle 7.5 (compare)

  • May 23 20:32
    Majkom commented #114
  • May 23 12:14
    Majkom commented #114
  • May 04 15:58
    azurvii opened #225
  • Apr 08 18:12
    kmbisset89 edited #224
  • Apr 08 18:11
    kmbisset89 opened #224
  • Apr 07 13:16
    kmbisset89 closed #223
  • Apr 07 13:16
    kmbisset89 commented #223
  • Apr 07 12:51
    kmbisset89 opened #223
  • Apr 01 04:04
    sdavids13 commented #221
  • Apr 01 04:02
    sdavids13 opened #222
  • Mar 31 21:14
    sdavids13 commented #221
  • Mar 31 20:19
    sdavids13 opened #221
  • Mar 31 17:28

    rpalcolea on main

    Gradle 7.4.2 (compare)

  • Mar 30 21:17
    kokiliquido opened #220
  • Mar 09 18:06

    rpalcolea on main

    Gradle 7.4.1 (compare)

Rob Spieldenner
@rspieldenner
I would start a 0.2.x branch until 0.1.0 was released
Rob Spieldenner
@rspieldenner
Or put release.version=0.2.0-SNAPSHOT in gradle.properties to hard code it for awhile
Rob Spieldenner
@rspieldenner
The plugin goes off of tags so if it hasn't seen a bigger tag to go off of it would keep on the 0.1.x release train.
Jean-François Moy
@jfmoy
I will try your suggestions, thank you very much for your help. Best wishes for 2016. Will come back to you as soon as I have figured something out based on what you said.
Jean-François Moy
@jfmoy
@rspieldenner I have experimented with what you said but unfortunately it does not work as expected:
  • Latest release was on 0.7.x branch (0.7.0)
  • I have three RCs in my 0.8.x branch
  • Doing commit in my 0.9.x branch. Can no longer run Gradle as version inference fails: > Invalid branch (release/0.9.x) for nearest normal (0.7.0).
gradle-git does not authorise for a delta between the latest normal and the current release of more than 1. Other problem is that fixing the version through gradle.properties means that the version won't receive feature branch suffix, or sha1 suffix etc.
I also tried tagging the repository with something like v0.9.x or v0.9.0-dev to see if it would pick it up, but it does not and stay on the release branch version inferring mechanism.
Rob Spieldenner
@rspieldenner
it definitely is a limitation of the plugin we're building on top of, we tend to not have 3 concurrent branches without releases going on
so generally I would have a 0.8.0 release before going very far in a 0.9.x branch
we're getting tired of the limitations of gradle-git as it applies to this plugin, but do not currently have time for a rewrite
since currently it works with our internal use cases
so with 0.8.x rcs out, we might be on the master branch, but not really caring what the version on the snapshots are
Jean-François Moy
@jfmoy
I see, we do a lot of testing on all our releases, so the three parallel branches can definitely co-exist:
  • currently released version in case of hot fix (patch)
  • rc for future version being Q/A'd
  • development team continues development on future release branch.
    Can you explain to me what your usage of master is? Actually ours is very limited as it contains what's currently on prod basically (so that would be the same as the content of the latest release, 0.7.0 in the case above).
Rob Spieldenner
@rspieldenner
so most of my projects don't use a gitflow model, so master is our development flow and we release when we have the set of features we planned for the next release
we have some project that maintain a current branch on master and legacy branches, 1.x, 2.x etc.
Jean-François Moy
@jfmoy
Okay so you basically develop in master (except for feature branches), then create a release branch simply for releasing (RCs and Final releases), and continue development in the mean time in master. Much simpler indeed I guess.
Rob Spieldenner
@rspieldenner
i think Genie is probably the only project that uses gitflow full on
Jean-François Moy
@jfmoy
We do mostly Android development but reused what we were used in doing with maven where git flow is largely used and plugins are numerous.
However, not against changing workflow, as gitflow is not without flaws (like what's the purpose of master anyway ;) )
James Bassett
@jamesbassett

Hi all. Issue tracker doesn't seem very active, so I thought I'd try here. We're looking at moving from git-flow to a simpler master+feature branches workflow, and I was hoping to use this plugin to automate releases.

We'd like to use maven-style SNAPSHOTs for builds off our feature branches, but the 'snapshot' task provided by this plugin doesn't cater for concurrent feature branches. In our current git-flow builds we support this via maven classifiers (e.g. develop gets 1.0.0-SNAPSHOT, feature/featureone gets 1.0.0-featureone-SNAPSHOT and feature/featuretwo gets 1.0.0-featuretwo-SNAPSHOT). Moving forward with just feature branches for development, the main issue is being able to consume either version of the artifact via Nexus, instead of both being published with identical maven GAV.

Is this something that could be integrated into the plugin, or will I have to fork? I'm happy to create a PR, but any pointers on implementation would be awesome!

Nadav Cohen
@nadavc
@jamesbassett have you tried the devSnapshot task?
Or do you specifically need Maven style SNAPSHOTs instead of specified builds?
*specific
James Bassett
@jamesbassett
short answer - yes we want maven snapshots.
long answer - yeah, I played with devSnapshot. I wasn't sure how to handle concurrent features using that either given the format is <major>.<minor>.<patch>-dev.#+<branchname>.<hash> (how do you target a specific feature when referring to the dependency?). Also, it requires setting up a cleanup task on Nexus (one to cleanup old semantic snapshots, and another one to cleanup the metadata which gets out of sync when the file is deleted)
Kirill Tolkachev
@lavcraft
Hi. Has nebula-release plugin supported multi project build with custom version for each subproject?
Kirill Tolkachev
@lavcraft
Like this:
        my-project:1.0.1
            ├── subproject-one:1.0.2
            ├── subproject-two:1.1.2
            └── subproject-three:1.0.4
Nadav Cohen
@nadavc
@jamesbassett we generally don't use Maven-style SNAPSHOTs internally, so unfortunately the scenario you need is unsupported by the plugin. I suppose this might work if you alter the jar task to include a classifier and the archiveName in the format you need, although I haven't tested it.
@lavcraft you could have different version "generations" (e.g. release/2.x, release/3.x) for different branches, but not per project in the same branch.
Rob Spieldenner
@rspieldenner
versions are based on the tag of the repository, so everything in one repo gets the same version
if things release on different cadences we believe they should be in different repositories
Rob Spieldenner
@rspieldenner

@jamesbassett I don't believe in feature branches, I think those situations are better handled with feature toggles in the develop/master branch -- the teams we have that need those use the devSnapshot way and we have cleanup scripts to reap artifactory of old jars that aren't used by any builds/production anymore

we are open to a pull request to switch the behavior on pure snapshots and I would prefer the branch names as a classifier on the jar

James Bassett
@jamesbassett

@rspieldenner thanks for the reply. I was open to the idea of using devSnapshot but didn't see how I could reliably pull in the latest version for a particular branch (using gradle's + operator in the version). I forgot about classifiers - I guess that will require configuring the maven publication? That might just work!

I tested the scheduled tasks in Nexus 3 to reap semantic snapshots and noticed that it didn't update the metadata, so I had to schedule another task to correct the metadata which I wasn't too happy about. Maybe it's a bug in Nexus.

As for feature branches, we're thinking of moving from git-flow to a simpler master+feature branch model (nebula-plugins/nebula-release-plugin#44). We're trying to get CD happening, so want to get to the stage where everything in master is deployable to production (and able to be feature toggled off if not). Feature branches are just a way to support concurrent features, while giving us a peer-reviewable PR. It also means we don't have a heap of interleaved commits to wade through.

I created a PR to support branch names in maven snapshots (nebula-plugins/nebula-release-plugin#45), but I'll take another look at devSnapshot with classifiers this time, and see if that can work for us instead.

Kirill Tolkachev
@lavcraft
@nadavc Thanks!
Kirill Tolkachev
@lavcraft
Hello folks!
How release only one submodule instead of whole project?
like this:
./gradlew :my-submodule-1:final
I had tried this, and have a next error as a result:

FAILURE: Build failed with an exception.

* What went wrong:
Task 'final' not found in project ':my-submodule-1'.

BUILD FAILED
i applied nebula release to all project:
allprojects {
  apply plugin: 'nebula.nebula-release'
It is impossible?
Nadav Cohen
@nadavc
Hi @lavcraft, this is by design. The release plugin applies most of its logic on the root project, and the expectation is that all projects will be released at the same time. Here's the code that shows it: https://github.com/nebula-plugins/nebula-release-plugin/blob/master/src/main/groovy/nebula/plugin/release/ReleasePlugin.groovy#L68
Kirill Tolkachev
@lavcraft
Yeah. thanks for explanation!
It is make me sad, because it is`t applicable for many my projects :(
adityavit
@adityavit
Hi Guys, would like to know, is there something which is delaying the merge of this pull request nebula-plugins/gradle-ospackage-plugin#207
casey-largent
@casey-largent
Hello - I am currently running into an issue where if I commit multiple times to a branch that has a build on it that it reverts back to 0.0.1 for the new version. I basically have to make sure that each and every commit has a tag associated to it
Is this expected behavior?
Justin Field
@fieldju
Hello
nickheniser
@nickheniser
Hi.. maybe this is a naive question and not 100% related to this project per se, but does anyone have a recipe to save the current version to be output at runtime via a getVersion() or something like this?
Bishal Jaiswal
@Bishalj
can we provide the versioning pattern in devSnapshots ?
durgadas54
@durgadas54
How can i remove "snapshot" from the jar name?