Add Environment Variable for each GV Variable #271
Conversation
In a recent Pull Request (GitTools#262), the decision was taken to, in the absence of setParameter being available in AppVeyor, to create environment variables that could then be accessible in the remainder of Build Script. I would like to suggest that this also makes sense for TeamCity. In my scenario, I want to use: ```/output buildserver``` but use the generated variables later in my psake build script. In order to do this, I have to call GitVersion twice. Using this approach should mean that I can access the created Environment Variables later in my psake script when I need them. Does that make sense?
|
I thought there was a reason that -exec and -proj exist such that you can access env vars and that there was some reason the vars wouldn't be usable (e.g. they would propagate out of the process) if set like this?
|
|
In my case, I am executing the call to GitVersion from within the same psake script, that I later want to use the variables that are created by GitVersion. You can see an example of this here: https://github.com/chocolatey/ChocolateyGUI/blob/develop/BuildScripts/default.ps1#L182 As a result, I don't have the option to use /exec or /proj. Unless I am missing something. |
|
Have you tested this? From what I understand your psake script executes GitVersion which sets the environmental variables then the process exists and those env variables are not available in psake. A process cannot set a parent processes env variables. |
|
AppVeyor actually collects the environmental variables and promotes them afaik |
|
Tested which part? The TeamCity alteration, or the AppVeyor one? I was waiting on the next release of GitVersion to test properly on AppVeyor, since the Pull Request was accepted. I haven't tested on TeamCity yet, but I will. Wanted to start the conversation to see if I was barking up the wrong tree :-) |
|
@JakeGinnivan I have just tested the AppVeyor implementation, and it looks like calling Does anyone have any thoughts as to what that "something" would be? I would really like to avoid having to call GitVersion twice, as I think that this it just plain wrong. Surely there is something that can be done to set the Variables from within |
|
For shouldly I call GitVersion then parse the json to get the variables I want. https://github.com/shouldly/shouldly/blob/master/build/rakelib/version.rake |
|
@JakeGinnivan yes, I have seen that approach, and that is actually what I am doing in the second call to GitVersion. That approach is fine, but then you have to remember to make the call to set the Build Number, etc, thing that the It almost seems as though, at least to me, that there is a use case for having:
Where you get both things. |
|
@JakeGinnivan also, for AppVeyor, I have to first call |
|
We probably need to do the branch normalisation when using /output json.. |
Yip, that would work to. |
|
I am going to close this PR as this suggested implementation simply wouldn't work as suggested here. Some additional work would be required as suggested by @JakeGinnivan to add branch normalisation when called with |
In a recent Pull Request (#262), the decision was taken to, in the absence of setParameter being available in AppVeyor, to create environment variables that could then be accessible in the remainder of Build Script. I would like to suggest that this also makes sense for TeamCity.
In my scenario, I want to use:
/output buildserverbut use the generated variables later in my psake build script. In order to do this, I have to call GitVersion twice.
Using this approach should mean that I can access the created Environment Variables later in my psake script when I need them.
Does that make sense?