I have a fresh build server and need to setup jenkins there. So I created a first user on the Mac mini, and used that user to install Jenkins on the machine.
Jenkins then created another user (Jenkins) on the Mac Mini.
I thought that correct way to proceed is to login as that Jenkins user (with Admin rights) and prepare the build environment as this Jenkins user.
But I cant install Visual Studio for MAC, cant install SourceTree... bcs even though Jenkins has Admin rights, I am getting
"You do not have permissions to open the application 'Install Visual
Studio for Mac' contact your administrator..." message.
But as I said the Jenkins user is Admin user. So am I doing it wrong? What user should prepare all the build tools? And if it is supposed to be the first user I created (after booting the Mac mini for the 1st time), how do I let Jenkins use the apps then? When I tried doing this on my macbook, jenkins couldnt use some of the build tools, bcs apparently it did not have the permissions to do so.
So what is the correct way to set up a jenkins environment, so I can install whatever tools I need, and Jenkins can use these during builds/deploys?
Any help appreciated, all the guides about jenkins speak of jenkins user, but none gave me an idea what is the best way to set this all up.
My 2 cents.
I have not worked with MAC. So some of my assumptions may be wrong or suggestions may be not applicable to you.
I have set up Jenkins mostly on Linux and a couple of times on Windows. I used to install Jenkins using the RPM package which, upon installation, will create a 'jenkins' user and group.
For start/stop/restart, I always use 'sudo' since Jenkins is installed as a service.
Other build related tools like Java, Maven etc, I always make sure that Jenkins can access them and execute them. ie, I give execute privilege on those tools.
The JENKINS_HOME directory, I used to create a symbolic link from the default home directory to a file system with enough storage. I will do the same for Jenkins log file.
The benefit of having those Jenkins/tool files/directories as part of a custom defined directory structure is that I do not need to remember installation paths of each tool. ie, I have my Jenkins, maven, java, sonarQube everything under a directory I know. Even if I set up these tools in different servers, I will stick to the same directory structure.
My suggestions to you.
Setup build tools which are to be used/accessed from Jenkins, set them up with your 'first user' and give execute privilege to Jenkins user/group.
Create a directory 'ci' and link or place all tools inside. You can further have subdirectories for app - for binaries/installed files, data - for generated data like Jenkins_home, log - to keep log files of these tools.
ci/jenkins
ci/sourcetree
ci/apache-maven
Suggestion 2 is initially time-consuming but it will save a lot of your time as you use the tools on a daily basis.
Related
Im a trainie and learning C# at the moment and have basic knowledge about how TFS and workspaces work.
Im using VS2017 in a VM which has access to TFS.
Problem
when i go in to VS2017 Source code control i can see the shared user workspace name. And when i try to use dev cmd or normal command prompt and type the tf workspaces, it does not show any workspace available and gives me the error "There is no corresponding workspace found on this computer".
Is there anyway to see it in CMD?
Reason
the reason i need to test this function is that, We have a Deploy .bat/.cmd file which calls the TFS for new update, do a Realase version and then put it to a given fix directoy.
Im sorry if i cant provide more details about the problem. Company Policy.
I could try to answer any further questions.
Thanks for the replies.
Unless you provide a filter such as owner, computer or workspace name, Team Foundation only displays information about the workspaces that you have created.
Command to get workspaces on current VM:
tf workspaces /owner:* /computer:* /server:teamserver
Workspace Commands
Note: To use the workspace command you must have the Read permission set to Allow.
Word of caution: Pulling down a release version from a bat file is normally a bad approach and can cause problems. I would recommend taking the opposite approach. Instead of running a bat file to trigger a build/deploy
have TFS trigger the deployment and workspace update by some action or manual action in order for it to control your process. You can always use the bat file for deployment steps just have TFS setup and call it for you.
I'm trying to package and deploy a wpf application. I used install shield and I have created the setup file. When I try running the setup file it keeps throwing this error code
1925: it needs admin privileges to run the setup.
How do I configure the setup file to be run by any user? Should I make any changes in the registry during the creation of setup file in install shield? Is there anyway to work around this problem?
Thanks
It sounds like you're trying to create a per-user installation. Since Windows Vista, this requires several steps, but was made simpler with Windows 7. I would check a verbose log in case it highlights any specific problems, and if not, follow this general advice:
If this is always a per-user installation, set General Information > Require Administrative Privileges to No and set the ALLUSERS property to empty.
If this is only conditionally per-user, leave them as Yes and 1 respectively, and use the MSIINSTALLPERUSER property with ALLUSERS=2 to select a per-user installation at run time. Note that this only works on Windows 7 (MSI 5.0) and later.
Ensure that your setup.exe, if you are using one, does not elevate. Set Required Execution Level to Invoker in the setup.exe tab of the Releases view.
If you are not using MSIINSTALLPERUSER, ensure that you are not installing any resources to any machine locations. This includes installation files to the ProgramFilesFolder, registry keys to HKEY_CLASSES_ROOT or HKEY_LOCAL_MACHINE, or other machine-level items such as Windows Services. Note that you may have to exclude services from MSIINSTALLPERUSER scenarios as well.
I have configured MAC OS X environment (SDKs, licenses, etc) under current user for build server and would like to reuse all the settings by a build agent. Jenkins was chosen as a good option but for some reason during installation it created a new user jenkins and launch the app under it, causing the environment setup to be not accessible (no SDKs, no licenses are found anymore).
Is it possible to install jenkins under current user?
Probably it could be installed under jenkins but then launched under current user?
Any other good options for me to consider are appreciated.
Try this: http://www.sailmaker.co.uk/blog/2013/04/02/advanced-jenkins-for-ios-and-mac/#Installing-Jenkins-itself
I’m also going to recommend installing Jenkins via Homebrew, to avoid
some nonsense in Jenkins’ own installer whereby it puts itself in
/Users/Shared/. You really don’t want that.
If you're free to reinstall however you'd like, I'd recommend re-installing as the user you want to use, using whatever type of install you prefer, and then simply copy over the old Jenkins data directory to the new installation's location, and then changing the permissions in that directory.
That is to say, the directory containing the config, plugin and job information (it may be something like /usr/lib/jenkins, but could vary).
Then, chown -R the data directory using the user:group info you want to use so Jenkins has access to the files.
I have used this type of method in the past to transfer all the data from one install to another totally separate install on the same box, and it has worked well (one could use this method to transfer the data to an install on another box, as well).
Note: I would highly recommend making a full backup of the data directory before doing this, in case anything goes awry.
I am using windows installer to create setup project.
How I can remove/delete application files from AppData\Roaming folder when application uninstalled.
I tried added a special folder and set DefaultLocaltion to [AppDataFolder] but it didn't working.
Do I need to do anything else?
I'd need to understand what you are trying to do to give you specific advice. In general what you are trying to do would be OK removing files from CommonAppDataFolder but not AppDataFolder as trying to clanup user data from multiple user profiles is not a best practice. Additionally trying to cleanup Roaming Profile User data is outright impossible because the other users aren't logged on.
You'll want to read:
Managing Roaming User Data Deployment Guide
Assuming you are trying to do what I think you are, you'll need a cleanup script / exe that you leave behind on uninstall and a custom action to write to the registry during uninstall ( MSI can't do this natively ) to call that script/EXE. You'll want to leverage the Active Setup trick as described here:
Using Active Setup to Repair User Settings
The way it'll work is your uninstall leaves the EXE and registry entry behind so that when a user logs on it's roaming data gets pulled down from the server to local and Active Setup realizes it hasn't run the script yet. The script runs (once) and the data is deleted. When the user logs off the data is replicated / deleted on the server. Then they log on again it doesn't run again.
By default Windows Installer does not remove the files created by your application, after the installation. To do that you need to either write your own custom action, that will run upon uninstall, or depending on the tool used for authoring the MSI, you can use built-in options for cleaning the application locations, as some tools have this support.
First, the prior situation: We have this project with a one-click build script. It's cobbled together with TFS Deployer + PowerShell + VB Script. TFS Deployer sits on the production machine, copies the new website files into a brand new directory, and then calls a VB Script that changes the IIS website to the new directory.
Now, I'm moving the team away from the horror that is TFS/MSBuild. I have a TeamCity build agent on a dedicated build server. A simple NANT script deploys the build artifacts from the build server to the production server through a shared folder. Simple, quick, and effective.
However, I haven't found either a way a) to run the VB Script remotely b) update the IIS site remotely with a different mechanisms (programmatically within the 1-click build). Windows Server 2003/IIS6. Any ideas?
Update: I solved this by creating another vbs that remotely called the old vbs I had through WMI. Thanks everyone!
If I were to head in any direction, I would consider setting up a WMI script to do the work and then configuring it on the server in question. I would have to think about how to easily include this into your automated build. I personaally have not worked with TeamCity yet, although I have attended sessions on how it works.
WMI might be able to run the script, as well, and act as a sort of service front end, so you may be able to reuse what you have already spent effort on.
Could you change the vbscript file into an ASP file in a different website on the same server? This would allow you to call it remotely.
We've used NAntContrib's mkiisdir task to create/modify a virtual directory on remote machines.
<mkiisdir iisserver="Staging" dirpath="c:\temp" vdirname="Temp" />
This should either create (if the vdir doesn't exist) or change the location (if the vdir already exists).
Generally, it seems the cleanest way to do this is to first delete the vdir with the deliisdir task, followed by a create.
<deliisdir vdirname="Temp" failonerror="false" />
<mkiisdir dirpath="c:\temp" vdirname="Temp" accessread="true" accesswrite="false" accessscript="true" enabledirbrowsing="false" authntlm="true" authbasic="false" authanonymous="false" appcreate="Pooled" />
Happy coding!