Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for non-default git branches #13

Open
kavink opened this issue Jul 27, 2014 · 8 comments
Open

Support for non-default git branches #13

kavink opened this issue Jul 27, 2014 · 8 comments
Assignees
Labels

Comments

@kavink
Copy link

kavink commented Jul 27, 2014

Ability to do releases for non-default git branches, e.g. instead of doing releases of master, Maybe a release has to be from branch cool-feature-1 across all repositories.

@akhikhl
Copy link
Owner

akhikhl commented Jul 27, 2014

Resolved in version 1.0.19.

The branch can be specified on two levels: globally and per-project:

multiproject {
  branch = 'niceFeature1'
  git baseDir: 'upstream_repos', {
    project name: 'project1', branch: 'niceFeature2'
    project name: 'project3'
    project name: 'project2', dependsOn: [ 'project1', 'project3' ]
  }
}

in the example above the projects project2 and project3 will be checked out to branch "niceFeature1", while project1 will be checked out to branch "niceFeature2".

@akhikhl akhikhl self-assigned this Jul 27, 2014
@kavink
Copy link
Author

kavink commented Jul 27, 2014

Thanks, Let me test this.

One quick question: Does the release plugin work in this?

Looks like release plugin has a parameter requireBranch, which defaults to master.

@akhikhl
Copy link
Owner

akhikhl commented Jul 27, 2014

I ignore this parameter. It is used solely in initScmPlugin task, and used
exclusively for checking that git repository is on the correct branch.
Since ARF is fully in control of branches (mind you, it performs clone),
there's no need for branch checks.

initScmPlugin is also checking that git repository has "gradle.properties"
containing "version=xyz" property.

Since I do "gradle.properties" check myself and branch check is not needed,
I got rid of call to initScmPlugin task altogether.

On Mon, Jul 28, 2014 at 12:12 AM, kavink [email protected] wrote:

Thanks, Let me test this.

One quick question: Does the release plugin work in this?

Looks like release plugin has a parameter requireBranch, which defaults
to master.


Reply to this email directly or view it on GitHub
#13 (comment)
.

@kavink
Copy link
Author

kavink commented Jul 27, 2014

Thanks! yes i tested it, Seems to be working. i Think i noticed a bug. If the repos are in any other branch.. say xyz and no branch= is configured it releases off that branch.

Should there be a default, if branch = is not specified then it should default to master and checkout master, if specified use that branch

Also would be good to do a log.warn on git actions like checking out branch , committing etc. So its easier to know what is happening.

@kavink
Copy link
Author

kavink commented Jul 28, 2014

Also seems to be another bug when a repo has a a default branch like develop and ARF is trying to do release off master branch, it does not pull latest changes but works of local copy of the branch. Also the the checkout does not have upstream setup. Probably few more commands from grgit needs to be tweaked. like when checking out a branch upstream should be setup and always a pull should be done after checkout

@kavink
Copy link
Author

kavink commented Jul 28, 2014

Looking at build.gradle, There are couple of things i noticed

  • Possibly while cloning we use need to use : refToCheckout: proj.branch
  • git checkout should have createBranch: false

i am not sure how to fix the error when repo already exist and we have to checkout the branch, maybe try to fetch from origin first and then checkout ?

@akhikhl
Copy link
Owner

akhikhl commented Jul 28, 2014

Thank you for very useful pointers. I'm now looking into the sources of grgit and starting to understand how to fix the issue.

@akhikhl
Copy link
Owner

akhikhl commented Jul 28, 2014

Fixed in version 1.0.22.

@akhikhl akhikhl added the fixed label Jul 28, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants