We delay sign assembly in DEV and when we build release I want to sign assembly. Key is in computer where is agent and access to private key is limited to some users, agent user included. I can add MSBuild parameters but I don't want to have hardcoded path to private key in every build definition. I think that I add User Capability to agent and than in task I use this capability value. But I don't know how to access value.
Is there way to get value from User Capabilities in task?
I don't think this is possible. The capabilities are designed to map with the demands defined in build definitions and thus define the pool of agents capable to run the build.
In order not to hardcode this in every build definition, you can define a variable with this value and then generate a template from your this definition. Next time you create the build definition from that template, the variable will be preset with the correct path.
Related
I m using CODEBUILD_BUILD_NUMBER in AWS Code build to append the build number to the artifacts that are deployed from the build. After every major version release, we need to again reset the build numbers.
For example, after v2.0.0-401 if we want to start building v3.0.0-1, not finding a way to reset the build numbers on the same code build project.
Any help is appreciated.
not finding a way to reset the build numbers on the same code build project.
This is because you can't reset it. Its managed by AWS.
You can setup new build project to start counting from zero if you want, or use different way of tagging your builds, not based on CODEBUILD_BUILD_NUMBER.
Yes this functionality is not available out of the box, but will be definitely useful.
For now my recommendation would be to keep your CUSTOM_BUILD_NUMBER in the SSM Parameter Store, CodeBuild has native integration with Param Store, providing easy way to lookup value:
https://docs.aws.amazon.com/codebuild/latest/userguide/build-spec-ref.html#build-spec.env.parameter-store
Every time I roll the version number I just track it in my buildspec instead of having to store things anywhere else.
- $buildPrefix = "2.0.0."
- $resetBuildNumber = 8 #this should be set to the build number prior to a buildPrefix version update
- $currentBuild = "$buildPrefix" + ($env:CODEBUILD_BUILD_NUMBER - $resetBuildNumber)
What I'm trying to achieve is the following:
I have multiple dependent configurations for a single, logical build. The very first configuration runs a script that does a bit of work and returns a value. You can think of this configuration as the setup step. I need to be able store this value and use it in subsequent steps. All dependent configurations for a single build should receive the same value.
Setup() computes a value x. I then have configurations B(x) and A(x) that run after Setup() and need to be fed the calculated value x.
Previously, I've managed to do something similar for things that are calculated as part of the TeamCity configuration. E.g. I generated a unique build id for the entire build chain and was able to access it via %dep.{team_city_configuration_id}.system.build.number%.
This time, the value I need to propagate is calculated in the guts of a build script and not as part of the TeamCity plumbing. I've managed to wrap the setup script in question and grep out the value I need, but I don't know how to propagate it between configurations.
Is this even possible, or am I barking up the wrong tree? If I cannot do this in a non-insane way, is there a better alternative I'm missing?
Thanks
Can a mod close this, please? It's a dupe. My colleague found this, which does exactly what we wanted.
I have several (15 or so) builds which all reference the same string of text in their respective build process templates. Every 90 days that text expires and needs to be updated in each of the templates. Is there a way to create a central variable or argument
One solution would be to create an environment variable on your build machine. Then reference the variable in all of your builds. When you needed to update the value you would only have to set it in one place.
How to: Use Environment Variables in a Build
If you have more than one build machine then it could become too much of a maintenance issue.
Another solution would involve using MSBuild response files. You create an .rsp file that holds the property value and the value would be picked up and set from MSBuild via the command line.
You need to place it into somewhere where all your builds can access it, then customize your build process template to read from there (build definitions - as you know - do not have a mechanism to share data between defs).
Some examples would be a file checked into TFS, a file in a known location (file share), web page, web service, etc.
You could even make a custom activity that knew how to read it and output the result as an OutArgument (e.g. Custom activity that read the string from a hardcoded URL).
I need to enumerate paths to desktop folders for all users on a local Windows system from a service application. The catch is that some users may not be logged in at the time. So is there any API, or some other method to do that?
EDIT1: For those who didn't read the first paragraph let me repeat -- I do not have a token to a user account, a user may not be logged in at the time.
EDIT2: I need this to remove a shortcut from user desktops before a feature supported by my application is turned off, or the app is uninstalled.
Here's the best method I was able to come up so far. So I'd appreciate if someone with a non-English installation of Windows could check this for me?
(I'm posting just a pseudo-code for brevity.)
1 - All of the steps below are done from a local service application.
2 - To get paths to all user profiles enumerate subfolders in the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList key and read ProfileImagePath value from them. It will give profile paths for each user account.
3 - To get the folder name for the desktop, read the Desktop value from the HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders key from the service app (yes, I know HKCU sounds strange, but it worked for me.) After that get the path for the %USERPROFILE% environment variable, using environment variable APIs. So you'll get two paths, something like this:
C:\Windows\system32\config\systemprofile\Desktop
and
C:\Windows\system32\config\systemprofile
Then simply isolate the 2nd string from the 1st, using case-insensitive comparison, and you'll get the folder name for the desktop, (i.e. "\Desktop" in this case.)
4 - Add the desktop folder to the path obtained in step 2 to produce the full path to that user's desktop folder.
From userenv.h : GetProfilesDirectory (win2k+, iirc)
msdn.microsoft.com/en-us/library/windows/desktop/bb762278(v=vs.85).aspx
Use this to find the directory containing all the local user account profile directories.
To find the desktop folder:
Shlobj.h : SHGetKnownFolderPath (vista+)
msdn.microsoft.com/en-us/library/windows/desktop/bb762188(v=vs.85).aspx
You'll need FOLDERID_Desktop as the known-folder id. This symbol is declared in Knownfolders.h
msdn.microsoft.com/en-us/library/windows/desktop/dd378457(v=vs.85).aspx
Using these, you might get closer to what you want without directly reading the registry. Of course this belies any elegant way of enumerating the users aside from inferring from the folder list within the
GetProfilesDirectory. Perhaps there is a more api appropriate way to enumerate the local users.
Secondly, and this depends on the purpose of your service, but perhaps by working with the 'allusers' profile, instead of each individually you won't need to know the current list of local users.
Day 1 with using Hudson for our CI build. Slowly but surely getting up to speed.
My question is about run parameters. I've seen that I can use them to reference a particular run of a particular project - that's all fine.
What I don't understand (and can't find any documentation on - there's nothing at Parameterized Build) is how I refer to anything in the run defined by the run parameter.
Essentially I want to reference the %BUILD_NUMBER% and %SVN_REVISION% of the run that is selected in the run parameter.
How can I do that?
Do you really need to add extra property values, extra parameters for your job?
Since BUILD_NUMBER and SVN_REVISION are already defined as environment variables (see Building a software project), you can use those in your job.
When a Hudson job executes, it sets some environment variables that you may use in your shell script, batch command, or Ant script
or:
illustrates you already have those values at your disposal.
You can then use them to define other environment variables/properties within your shell or ant script.
When it comes to pass a variable value from one job to another, the Parameterized Trigger Plugin should do the trick:
The parameters section can contain a combination of one or more of the following:
a set of predefined properties
properties from a properties file read from the workspace of the triggering build
the parameters of the current build
"Subversion revision": makes sure the triggered projects are built with the same revision(s) of the triggering build.
You still have to make sure those projects are actually configured to checkout the right Subversion URLs.
Note: there might be an issue with the Join Plugin, which might not work when the Parameterized Trigger is in action.