I am facing a genuine problem and not sure what exactly are the keywords for the same.
I have a c project and using Embedded arm tool chain to build it.There is a configuration file and some C/C++ Linker settings of Macros/hash Defines which needs to be changed for a a given configuration.
Customer keeps asking us to change those configuration and build and send the binaries to the customer.There is now 100s of such combinations and the task is quiet monotonous and cumbersome.
We dont want to say NO to customer , also don't want to share this source code.
I am thinking of a system(web based or any other thing) where the customer has the access to these files and he can invoke the build commands by changing this file and passing the MACROS on the command lines and get the binaries.
How can I achieve it?
Update : I have googled and talked to few people and teh answer is this can be partially Achieved using Jenkins
Related
I want to display non-code differences between current build and the latest known successful build on Jenkins.
By non-code differences I mean things like:
Environment variables (includes Jenkins parameters) (set), maybe with some filter
Version of system tool packages (rpm -qa | sort)
Versions of python packages installed (pip freeze)
While I know how to save and archive these files as part of the build, the only part that is not clear is how to generate the diff/change-report regarding differences found between current build and the last successful build.
Please note that I am looking for a pipeline compatible solution and ideally I would prefer to make this report easily accessible on Jenkins UI, like we currently have with SCM changelogs.
Or to rephrase this, how do I create build manifest and diff it against last known successful one? If anyone knows a standard manifest format that can easily be used to combine all these information it would be great.
you always ask the most baller questions, nice work. :)
we always try to push as many things into code as possible because of the same sort of lack of traceability you're describing with non-code configuration. we start with using Jenkinsfiles, so we capture a lot of the build configuration there (in a way that still shows changes in source control). for system tool packages, we get that into the app by using docker and by inheriting from a specific tag of the docker base image. so even if we want to change system packages or even the python version, for example, that would manifest as an update of the FROM line in the app's Dockerfile. Even environment variables can be micromanaged by docker, to address your other example. There's more detail about how we try to sidestep your question at https://jenkins.io/blog/2017/07/13/speaker-blog-rosetta-stone/.
there will always be things that are hard to capture as code, and builds will therefore still fail and be hard to debug occasionally, so i hope someone pipes up with a clean solution to your question.
I have questions about how to best integrate Tensorflow with my team's existing iOS application.
I am currently adding Tensorflow to an existing iOS project. I built the library for iOS following the instructions in the makefile README.md, and was able to compile successfully.
I have now been trying to follow the instructions here to get the library integrated. These instructions tell you to add search paths to a number of folders in your Tensorflow build, which will cause problems as I need this project to be easily sharable with my team in git. I would prefer to not have to force anyone else working on this to run a 20-plus minute build before they can get up and running.
The options I've considered are below:
Option 1: Embed the entire Tensorflow library
The problems here would be making the size of the project enormous. In addition, the build time will be significant and unnecessary. How often would we build to keep updated? I would like to avoid this.
Option 2: Link to separate Tensorflow project
With this option we would statically link to a peer project and have the same structure on each developer's machine. This seems to imply we'd have to have each team member pull and build the Tensorflow library before being able to build our project at all. Is there a way with this option to copy over only the necessary output files when they're updated by someone who has built Tensorflow while at the same time not requiring developers to build Tensorflow on their machine?
I'm also curious if there is a 3rd option I haven't considered here.
The usual way I think about this is by treating TensorFlow as a framework. That means that you need to build a copy once, and can then share the resulting files as something you can distribute to other developers in your organization.
You should just be able to zip up the folder you've built TF in (the directory you cloned from github) after you've built it, and then have other developers install it in a known location on their machine. I think this is what you're saying with option #2, but the difference is that other developers can avoid building it, unless they want to.
This also has the advantage that you can make sure your team members are all on the same TensorFlow version, to make debugging a bit easier.
Does that help?
Background
I am developing an iOS app that connects to a server. We have a team of developers who run their own server with unique addresses for debugging. Our rule for source control is to only checkin the "production url".
In Android we have a solution that works really well. This solution won't work in iOS.
What I've Tried
Set a "Command line argument" or "Environment variable" in the Build Scheme. The problem with this is those are put into the "*.xcproject" file which get's checked in and causes merge conflicts. If it could be set at the user level it would be fine because we .gitignore xcuserdata.
I also tried referencing a "MyConfig.h" file that does not get checked in. But if it does not exist the project won't build.
What I want to do
If a developer wants to point at a different server they would set an environment variable on their mac. Something like "export MY_SERVER="http://domain.com/api/". In the project file we would add and environment or command line argument that is basically "MY_SERVER=$(MY_SERVER)".
Unfortunately I can't figure out how to get XCode to resolve the variable on my OSX machine. It seems environment variables are resolved on the device only. Command line arguments seem to be taken literally.
Research I've done
http://qualitycoding.org/production-url/ - does not really address the real issue
http://nshipster.com/launch-arguments-and-environment-variables/
Google, Apples developer forum and Stackoverflow post.
How do you do this in your projects ?
Is the only solution to use a backdoor or some file folks change and just try not to accidentally checkin?
As an update I found the solution that solves the problem for me. I am using https://github.com/xslim/mobileDeviceManager and a script that is checked in. The developer can create their custom configuration and copy it to the documents directory. Now we keep production checked in and have a runtime check for our custum configuration file.
Here is an example of the tools usage:
$ mobileDeviceManager -o copy -app "com.domain.MyApp" -from ~/.myAppConfig/app_override.plist
This way the developer can keep their custom configuration in their home directory (out of source control) without fear of accidental checkin. We already use process like this for other desktop and android apps so this fits our process really well. This has the added benefit that if a testers device is failing we can point it at a custom debug server with extra logging to simplify the debug process and not need to deploy a new binary to that device during internal testing.
I hope this can help someone else.
We have an automated build and QA process for our software, using tfs/teambuild and msbuild, and we want to be able to know (for audit purposes) whether a component has gone through that process or not.
For example, if a library is installed on a user's machine, I'd like to be able to inspect it in some way to tell that it went through the build. In particular, I want to be able to distinguish it from components built directly on a developer's machine, and then manually installed.
What is the best way to do this? Code signing as part of the build process seems closest to these requirements, but presumably this would not cover any 3rd-party libraries that might be used? I also read about the ILMerge tool to merge all assemblies into one, but then I don't know enough to work out whether they can then be signed or not?
I'm sure we're not the first people to have the requirement, so casting around for any ideas or hints from others who might have done such a thing
Thanks!
Our developer builds are set to keep the versions at "0.0.0.0", but our build server marks the build based on a pre-configured version and automagically generated build string. "1.0.3.xxx". Your build server doesn't allow for this?
Your build process should be updating each of your projects assemblyinfo.cs files (or a global linked equivalent), you can do this with the TFS changeset number, so like the previous poster indicated you end up with the property on each dll of 1.0.changeset.buildno or something similar. You can do this easily in msbuild.
You could have the values of each assembly info file set in source control to be something obvious like 0 or 999.
A lot of what your asking is about process and training as well though.
If your using installers or zips to package your deliverables then you can also label them with the build number as part of your build process.
But if you have changeset you have the link from dll to code, so traceable, coupled with links to third party dll references as defined in each csproj.
I'm just getting started with the team build functionality and I'm finding the sheer amount of things required to do something pretty simple a bit overwhelming. My setup at the moment is a solution with a web app, an assembly app and a test app. The web app has a PublishProfile set up which publishes via the filesystem.
I have a TFS build definition set up which currently builds the entire solution nightly and drops it onto a network share as a backup of old builds. All I want to do now is have the PublishProfile I've already setup publish the web app for me. I'm sure this is really simple but I've been playing with MSBuild commands for a full day now with no luck. Help!
Unfortunately sharing of the Publish Profile is not supported or implemented in MSBuild. The logic to publish from the profile is contained in VS itself. Fortunately the profile doesn't contain much information so there are ways to achieve what you are looking for. Our targets do not specifically support the exact same steps as followed by the publish dialog, but to achieve the same result from team build you have two choices, I will outline both here.
When you setup your Team Build definition in order to deploy you need to pass in some values for the MSBuild Arguments for the build process. See image below where I have highlighted this.
Option 1:
Pass in the following arguments:
/p:DeployOnBuild=true;DeployTarget=PipelinePreDeployCopyAllFilesToOneFolder;PackageTempRootDir="\\sayedha-w500\BuildDrops\Publish";AutoParameterizationWebConfigConnectionStrings=false
Let me explain these parameters a bit, show you the result then explain the next option.
DeployOnBuild=true:This tells the project to execute the target(s) defined in the DeployTarget property.
DeployTarget=PipelinePreDeployCopyAllFilesToOneFolder: This specifies the DeployTarget target.
PackageTempRootDir="\\sayedha-w500\BuildDrops\Publish": This specifies the location where the package files will be written. This is the location where the files are written before they are packaged.
AutoParameterizationWebConfigConnectionStrings=false: This tells the Web Publishing Pipeline (WPP) to not parameterize the connection strings in the web.config file. If you do not specify this then your connection string values will be replaced with placeholders like $(ReplacableToken_dummyConStr-Web.config Connection String_0)
After you do this you can kick off a build then inside of the PackageTempRootDir location you will find a PackageTmp folder and this contains the content that you are looking for.
Option 2:
So for the previous option you probably noticed that it creates a folder named PackageTmp and if you do not want that then you can use the following options instead.
/p:DeployOnBuild=true;DeployTarget=PipelinePreDeployCopyAllFilesToOneFolder;_PackageTempDir="\\sayedha-w500\BuildDrops\Publish";AutoParameterizationWebConfigConnectionStrings=false
The difference here is that instead of PackageTempRootDir you would pass in _PackageTempDir. The reason why I don't suggest that to begin with is because MSBuild properties that start with _ signify that the property in essentially "internal" in the sense that in a future version it may mean something else or not exist at all. So use at your own risk.
Option 3
With all that said, you could just use the build to package your web. If you want to do this then use the following arguments.
/p:DeployOnBuild=true;DeployTarget=Package
When you do this in the drop folder for your build you will find the _PublishedWebsites folder as you normally would, then inside of that there will be a folder {ProjectName}_Package where {ProjectName} is the name of the project. This folder will contain the package, the .cmd file, the parameters file and a couple others. You can use these files to deploy your web.
I hope that wasn't information over load.
The ability to publish web sites, configure IIS and push schema changes for the DEV->QA->RELEASE cycle has required either custom configuration to imitate publish or custom code where IIS settings are involved.
As of Visual Studio 2013.2 Microsoft has added a third party product that manages deployment of web sites, configuration changes and database deployment with windows workflow and would be the recommended solution for automating deployment from TFS build.
More information can be found here:
http://www.visualstudio.com/en-us/explore/release-management-vs.aspx
You can use the Publish/Deploy in Visual Studio 2010.
See http://www.ewaldhofman.nl/post/2010/04/12/Auto-deployment-of-my-web-application-with-Team-Build-2010-to-add-Interactive-Testing.aspx for more information