We're using xcodebuild command line to build our nightly jobs, specifying project, target, and configuration.
It seems like the build is done with "Parallelize build" set to "YES" by default, although we're not using schemes for the nightly builds.
This causes build errors (in detail: lipo tool tries to create a universal binary before both architectures complete building).
How can I disable the parallelization in the command line without having to create a scheme?
Ok, I've created a shared scheme (so I could later save it in the source control) and used it to define the parallelization state. That worked for me.
Related
This is the command-line used install MySQL silently,
/quiet
But how to run the MySQL installer unattended with custom settings in the installer?
UPDATE: A newer and somewhat related answer here.
UPDATE: Several stages of answers here. I will leave them all in. The proposed technical solution / workaround moved to the top.
Instance Configuration
The actual configuration of instances seems to have been moved from MySQLInstanceConfig.exe to the installer itself: Where is the MySql 5.6 equivalent of `MySQLInstanceConfig.exe` to edit configuration files? Please try the MySQLInstallerConsole.exe (note: that links to version 8.0, not 5.7) application, sample:
Silent Installation: It seems this console appliation can run the installation silently in
various flavors, making the procedure below optional.
MSI Packages
I did a test run of what I believe was the mysql-5.7.22-winx64.msi file (there are many MSI files embedded in the main one, please see below). My best tip: get on the phone with the vendor to determine if they have actively tried to prevent silent installation. They just might have, and then you might be fighting windmills over time. They should improve this design if you ask me - though it is not the worst I have seen.
By launching the original, large MSI and enabling automatic logging (see section in that link: "Globally for all setups on a machine"), then running through its built-in, custom GUI and kicking off the actual install and then checking the "CommandLine" entry in the actual log file generated in the temp folder - it looks like it sets the following properties: REBOOT, ADDLOCAL, INSTALLDIR, INSTALLLOCATION, ARPINSTALLLOCATION, INSTALL_ROOT, DATADIR. Actual log entry below:
******* Product: C:\ProgramData\MySQL\MySQL Installer for Windows\Product Cache\mysql-5.7.22-winx64.msi
******* Action:
******* CommandLine: REBOOT=ReallySuppress ADDLOCAL=RegKeys,ALWAYSINSTALL,Readme,MISC,Server_Scripts,ProgramMenu,MYSQLSERVER,Client,DEVEL,SharedLibraries,UserEditableDataFiles INSTALLDIR="C:\Program Files\MySQL\MySQL Server 5.7" INSTALLLOCATION="C:\Program Files\MySQL\MySQL Server 5.7" ARPINSTALLLOCATION="C:\Program Files\MySQL\MySQL Server 5.7" INSTALL_ROOT="C:\Program Files\MySQL\MySQL Server 5.7" DATADIR="C:\ProgramData\MySQL\MySQL Server 5.7" ALLUSERS=1
These are in other words the properties set by the custom setup GUI that normally runs the installation process. You should be able to use this procedure for all the embedded MSI files you need to install. Then you simply extract these MSI files that you need from the large MSI and run them in sequence in some fashion, with the command lines you have found. You can also apply transforms if need be.
To state the obvious: this might take you some time to get right as you struggle with pre-requisites and your corporate use case. I'd go for piloting. Find a dynamic team and get your stuff on their test PCs quickly and tell them to give it a trashing asap :-). Chances are you already do, just mentioning it. I for one can never get these things right without some unfortunate, time-consuming iterations.
Summary of procedure:
Enable automatic logging (MSI expert Stefan Kruger's info)
Install via custom setup-GUI with options set as appropriate
Find properties to set in the log file in the %temp% folder.
Log file will have random name, sort by data and open most recently changed log file.
Get hold of the embedded MSI files from the wrapper setup:
Get hold of an MSI tool for viewing / editing MSI files (list towards bottom)
Delete launch conditions from wrapper setup (LaunchCondition table)
Extract content like this: msiexec.exe /a mysql-installer-community-5.7.22.1.msi TARGETDIR=C:\YourFolder
Tha above command kick off an administrative installation - essentially a glorified file extract, but a very good feature of MSI used by application packagers every day
Try to install on a test machine with an msiexec.exe command line based on the properties you found set
Sample:
msiexec.exe /i mysql-5.7.22-winx64.msi REBOOT=ReallySuppress ADDLOCAL="RegKeys,ALWAYSINSTALL,Readme,MISC,Server_Scripts,ProgramMenu,MYSQLSERVER,Client,DEVEL,SharedLibraries,UserEditableDataFiles" INSTALLDIR="C:\Program Files\MySQL\MySQL Server 5.7" INSTALLLOCATION="C:\Program Files\MySQL\MySQL Server 5.7" ARPINSTALLLOCATION="C:\Program Files\MySQL\MySQL Server 5.7" INSTALL_ROOT="C:\Program Files\MySQL\MySQL Server 5.7" DATADIR="C:\ProgramData\MySQL\MySQL Server 5.7" ALLUSERS=1 /QN
And some parameter info:
ADDLOCAL="..." - list of features to install locally
REBOOT=ReallySuppress - prevent spontaneous reboot
ALLUSERS=1 - install per machine
/QN - crucial addition to the command line found in the log file. this makes the install run in silent mode
Unusual MSI Design: I know this is an unusual MSI, but generally you call the vendor or search their website to obtain documentation for deployment such as this and follow the procedure I outline below (let me add the link here too: How to make better use of MSI files) using PUBLIC properties or transforms to modify the installation.
However, I wrote the section below before I did a quick check of this MSI. A quick look revealed a myriad of embedded MSI packages. Not at all good. The MSI also has no GUI, and its administrative installation (file extraction) is blocked with a launch condition. Quite terrible design in fact. You can make an administrative installation by deleting the launch conditions using Orca or an equivalent tool and going:
msiexec.exe /a mysql-installer-community-5.7.22.1.msi TARGETDIR=C:\YourFolder
It seems the idea is that this is a wrapper MSI which will launch a proprietary GUI (.NET based?) that you can then use to install the bits and pieces you need of the MySQL tool suite. It would have been much better if this launcher was a setup.exe built with WiX Burn, Installshield, Advanced Installer or an equivalent tool.
Recommended Procedure: The honest answer is that I don't know. I would call the vendor if possible, check their user forums and do some further googling in general. Most of the embedded MSI files should be possible to install in silent mode, I would hope.
The real-world approach would probably be to extract all the MSI files using the above administrative installation trick, although there must be a reason why they block administative installations - which I am unaware of. Most likely they do not want to support silent installation with options? (give them a call?). Then you take the individual MSI files you need, and see if they will install in silent mode using the approach described here with PUBLIC properties and / or transforms. There are many features in these setups, and you can use ADDLOCAL at the command line to define which ones to install and not. See the linked answer below. However, as I state below as well; feature control is a very complex topic (recommended skim).
Beware of pre-requisite runtime requirements. There may be several, such as the .NET framework and various runtimes. I see several of these being installed by the custom setup GUI.
My original, generic answer below:
MSI: It looks like this installer is in Windows Installer format, in other words an MSI file. You are in luck in the sense that MSI files are very flexible with regards to silent installation and the configration of custom paramenters. It is, however, dependpent on the package being well-designed, which is not always the case.
PUBLIC PROPERTIES and Transforms: I have an ancient answer here on the topic of customizing MSI installations: How to make better use of MSI files (just the first parts, the ending flies a bit off the handle with other topics). As you will see in the linked answer, you essentially set available PUBLIC properties at the command line, or create a transform to customize anything you want in the installer. The latter is what most corporations do for deployment.
Configuration: What properties can be set at the command line (that has any effect), varies between different setups. The setup creator must have made these properties - and built functionality around them in the setup - for them to be configurable. Typical parameterized values would include license keys, URLs to license servers and user and company names and emails and similar. For more substantial changes (such as changing shortcuts or similar), people usually resort to using a transform. You also use the ADDLOCAL property to define which features to install (all other features will not be installed if you specify a value for ADDLOCAL). Feature control is a built-in property of MSI, and you can control feature selection in detail from the command line or via a transform. However, feature control is a very complex topic (recommended skim).
Concrete Sample: As mentioned above you need to set properties and values as appropriate for the setup in question. This means you have to hit the documenation for the setup in question to determine what is "settable" or not.
Some Links:
https://downloads.mysql.com/docs/refman-5.7-en.pdf
https://dev.mysql.com/doc/mysql-installation-excerpt/5.5/en/windows-using-installer.html
I built Chromium from the source code (ninja -C out/Debug chrome) and make sure it works. After I executed:
git pull
gclient sync
ninja -C out/Debug chrome
The build system actually starts to building all the parts of the project again. Is it possible to rebuild only the changed parts of chromium?
Always do release build if you don't want to debug chrome browser.
Use ninja -C out/Release chrome to perform a release build. Debug build takes time in linking.
git pull updates your code and gclient sync syncs or sets the HEAD of the repo to the Last Known Good Revision(LKGR). Hence, no. of changed files plus no. of files which were dependent on that would be recompiled again.
From the windows build instructions it lists this build parameter:
is_component_build = true - this uses more, smaller DLLs, and incremental linking.
Execute:
gn args out/WhateverYouWant
Add
is_component_build = true
to the text file, save it, and close it.
For every build after the first it won't compile any components that you haven't changed.
I am just getting started with Packer, and have had several instances where my build is failing and I'd LOVE to log in to the box to investigate the cause. However, there doesn't seem to be a packer login or similar command to give me a shell. Instead, the run just terminates and tears down the box before I have a chance to investigate.
I know I can use the --debug flag to pause execution at each stage, but I'm curios if there is a way to just pause after a failed run (and prior to cleanup) and then runt he cleanup after my debugging is complete.
Thanks.
This was my top annoyance with packer. Thankfully, packer build now has an option -on-error that gives you options.
packer build -on-error=ask ... to the rescue.
From the packer build docs:
-on-error=cleanup (default), -on-error=abort, -on-error=ask - Selects what to do when the build fails. cleanup cleans up after the previous steps, deleting temporary files and virtual machines. abort exits without any cleanup, which might require the next build to use -force. ask presents a prompt and waits for you to decide to clean up, abort, or retry the failed step.
Having used Packer extensively, the --debug flag is most helpful. Once the process is paused you SSH to the box with the key (in the current dir) and figure out what is going on.
Yeah, the way I handle this is to put a long sleep in a script inline provisioner after the failing step, then I can ssh onto the box and see what's up. Certainly the debug flag is useful, but if you're running the packer build remotely (I do it on jenkins) you can't really sit there and hit the button.
I do try and run tests on all the stuff I'm packing outside of the build - using the Chef provisioner I've got kitchen tests all over everything before it gets packed. It's a royal pain to try and debug anything besides packer during a packer run.
While looking up info for this myself, I ran across numerous bug reports/feature requests for Packer.
Apparently, someone added new features to the virtualbox and vmware builders a year ago (https://github.com/mitchellh/packer/issues/409), but it hasn't gotten merged into main.
In another bug (https://github.com/mitchellh/packer/issues/1687), they were looking at adding additional features to --debug, but that seemed to stall out.
If a Packer build is failing, first check where the build process has got stuck, but do the check in this sequence:
Are the boot commands the appropriate ones?
Is the preseed config OK?
If 1. and 2. are OK, then it means box has booted and the next to check is the login: SSH keys, ports, ...
Finally any issues within the provisioning scripts
I am new in Hudson.
I would like to execute a 'sourcecodeanalyzer' command in Hudson as Post-build Actions to generate an html report. Please let me know is this at all possible, if yes let me know the Hudson configuration steps to execute the command.
Your earliest response in this regard will be extremely helpful.
Thanks in advance.
Yes, it is almost certainly possible.
You will need to configure the Hudson project to have either a post-build action or a build step that runs your source code analyzer.
You've not stated in your question precisely which analyzer - it may be that Hudson already has a plug-in installed for it, in which case it may be listed on the Config page for the project at the bottom under Post-build Actions.
If not, next check to see if there's a plug-in available for the analyzer that hasn't been installed. From the main Hudson page select Manage Hudson, then Manage Plugins, and choose the Available tab. If there is a plug-in available it's definitely a good idea to use it as they are generally very well integrated with Hudson itself.
As a last resort you'll have to configure a build step to run the analyzer. Configure the project, then choose "Add build step". The drop-down that appears depends on your environment (Windows or Linux) but should include the ability to run a shell command or batch file. You can configure your analyzer there.
(If you're building Windows Visual Studio applications, a more flexible way that I've used is to use the MSBuild plug-in for builds, and have an MSBuild script that builds the application and then runs analysis tools. This can automate pretty much everything: mine builds the application, builds an acceptance test database, runs the acceptance tests and copies the result HTML to a page linked from the project.)
You could create a new job with a "Execute Shell" build step. Type in the command you wish to run in the text box. Then all you have to do is trigger this job by selecting:
"Build after other projects are built"
And select the trigger job from the list.
Hope this helps!
As a follow up to Jeremy's post. If you don't see the ability to add post build steps, you might work with maven jobs. In that case you need the Hudson M2 Extra Steps Plugin. This will give you pre and post build steps.
I use the 'Post build task' plugin to delete some resources after a build. You could call any shell script or command lines. If you want you could make the call depends on some logging output.
there is one best way to solve this:
Upgrade to Fortify SCA 2.6.x (as of writing, latest version is 2.6.5).
Download the Fortify Maven Plugin version 2.6 from https://customerportal.fortify.com and install it into your Hudson server's Maven repository.
Update your project's pom to carry out the Fortify scan. There is an example provided with the Maven plugin.
Currently , I am experiment with sonar plug in. It looks great check the details here
http://sonar.codehaus.org/a-new-hudson-plugin-for-a-closer-integration-with-sonar/
http://wiki.hudson-ci.org/display/HUDSON/Sonar+plugin
I am setting up a new Hudson task (on WinXP) for a project which generates javascript files, and performs xslt transformations as part of the build process.
The ant build is failing on the XSL transformations when run from Hudson, but works fine when the same build on the same codebase (ie in Hudson's workspace) is run from the command line.
The failure message is:
line 208: Variable 'screen' is multiply defined in the same scope.
I have tried configuring Hudson to use both ant directly and to use a batch script - both fail in Hudson.
I have tried in Firefox, IE6 and Chrome and have seen the same issue.
Can anyone suggest how we can workaround this problem with Hudson?
Problem solved.
Our build is actually dependent on jdk 1.4.2, and Hudson appears to run using 1.6. When I set Hudson to run as a service, it ran as my local user, which meant that it picked up the 1.4.2 JAVA_HOME environment variable - and therefore worked.
I guess another possible solution is to configure Hudson to use 1.4.2 by default.
I would assume this is not an issue with Hudson directly, as it is with the build script and/or the environment itself.
Is your build script relying on certain environment variables being defined, or worse, the job running from within a certain directory structure (i.e. it works if it's run from under /home/mash/blah but not from under another directory like /tmp)? Is the build script making reference to external files by relative paths?
These are the things I would look into. For environment variables, you can tell Hudson to pass these into Ant. For the other issues, you probably want to change your build script. Check the console output provided by Hudson, and maybe set Ant to print verbose/debug messages to get a better idea about the environment/filepaths.