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

Git source control: added an optional 'revision' configuration property #163

Closed
wants to merge 2 commits into from

Conversation

JoseMarcenaro
Copy link

In cases where the CCNET tool is used to manually launch a test or release build, and Git source control is used, it would be helpful to specify - with a dynamic parameter - a specific revision (tag name, or even commit hash) to checkout and build.

This proposed patch is an update of the existing Git.cs class (and its unit test) implementing this feature as an added 'revision' configuration element (optional, default empty)

This feature addresses the same need described by Scott Vercuski 2 months ago in this entry

@dnauck
Copy link
Member

dnauck commented Feb 17, 2013

Hi,

is it really needed to add a second property that is nearly the same as the branchproperty?
Have you tested to specify your tag in the branch property? It should work, too.

RubenWillems added a commit that referenced this pull request Jul 13, 2014
added option to unload dashboard : System.Web.HttpRuntime.UnloadAppDomain()
@savornicesei
Copy link
Contributor

Hi @JoseMarcenaro @dnauck @RubenWillems @mintsoft
IMHO this should not be merged.

I've been looking for the past 2 days at how CC.NET and Jenkins implemented Git as source control and Git support in CC.NET is pretty rudimentary (10yrs ago SVN was ruling the Earth 😄 ).
CC.NET should detect if given branch name is a branch, a tag, a commit that's not a HEAD and do the proper checkout (see issue #273 ).

Best,
Simo

@JoseMarcenaro
Copy link
Author

Hi @savornicesei

Yes, that would be a better implementation. I agree.
Seven years ago I coded this 'revision' feature as a workaround for a specific need, but the proposed solution is better.

Regards,
Jose

@linquize
Copy link
Contributor

Could you rebase onto latest master?

@RubenWillems
Copy link
Member

RubenWillems commented Aug 26, 2019 via email

@mintsoft
Copy link
Contributor

mintsoft commented Aug 26, 2019

@RubenWillems I think what @linquize meant is that if @JoseMarcenaro rebases his fork from master, the conflicts will go away as @JoseMarcenaro will have to solve them when he rebases. Then we should be able to single-click-merge the PR on github as it'll be unconflicted

@RubenWillems
Copy link
Member

RubenWillems commented Aug 26, 2019 via email

@JoseMarcenaro
Copy link
Author

Hi guys
It's been 7 years since I added this (proposed) feature in my branch, and the repository code has evolved a lot since.

I did a quick check of what the rebase would require, but there are many (27) conflics in the core Git.cs class.
I'm really not confortable with trying to solve the multiple conflicts in a code that I'm no longer using and will not be able to test thoroughly before committing.

If this PR code can inspire you to implement a similar feature on top of the current code, go ahead.

@mintsoft
Copy link
Contributor

It's probably best to close this PR then @JoseMarcenaro we've got it for reference anyway :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants