I use Jenkins to configure my multiconfiguration build, which is like a snapshot.
The Axes I use are:
Labels: Mac10.6, Mac10.7, and Windows
Platforms: Mac10.6, Mac10.7, WinXP, Win7, and WinServer2008
Tasks: _App_Installer_, ATS, and so on
It is clear that it makes no sense for WinXP to build on label Mac10.6. Although it is shown as diabled/unconfigured, it still confuses people.
So is there any way to remove the useless configuration?
Inside the matrix/multiconfiguration plugin there is a field to filter out the combination available from the combination checkbox.
If you want to only execute windows with windows platform :
label=="Windows" && (platform=="WinServer2008" || platform=="WinXP" || platform=="Win7")
Of course in your case you'll have to handle a huge expression but it's doable.
I hope this helps you!
I had a similar problem. The workaround (by no means complete) was the following:
Separate builds for unrelated platforms (Mac, iOS, and Windows, for example) into different jobs.
Conduct a code review with the team explaining to them how matrix builds work.
But the truth of the matter that I also would like to see the matrix entries that do not pass the filter as blank, not disabled.
Related
Note: this is not a dupe of this or this other question. Read on: this question is specific to the Code-Sharing template.
I am doing some pretty basic experiments with NativeScript, Angular and the code sharing templates (see: #nativescript/schematics).
Now I am doing some exploration / poc work on how different "build configuration" are supported by the framework. To be clear, I am searching for a simple -and hopefully official- way to have the application use a different version of a specific file (let's call it configuration.ts) based on the current platform (web/ios/android) and environment (development/production/staging?).
Doing the first part is obviously trivial - after all that is the prime purpose of the code sharing schematics. So, different versions of the same file are identified by different extensions. This page explain things pretty simply.
What I don't get as easily is if the framework/template supports any similar convention-based rule that can be used to switch between debug/release (or even better development/staging/production) versions of a file. Think for example of a config.ts file that contains different parameters based on the environment.
I have done some research in the topic, but I was unable to find a conclusive answer:
the old and now retired documentation for the appbuilder platform mentions a (.debug. and .release.) naming convention for files. I don't think this work anymore.
other sources mention passing parameters during the call to tns build / tns run and then fetching them via webpack env variable... See here. This may work, but seems oddly convoluted
third option that gets mentioned is to use hooks to customize the build (or use a plugin that should do the same)
lastly, for some odd reason, the #nativescript/schematics seems to generate a default project that contains two files called environment.ts and environment.prod.ts. I suspect those only work for the web version of the project (read: ng serve) - I wasn't able to get the mobile compiler to recognize files that end with debug.ts, prod.ts or release.ts
While it may be possible that what I am trying to do isn't just supported (yet?), the general confusion an dissenting opinions on the matter make me think I may be missing something.. somewhere.
In case this IS somehow supported, I also wonder how it may integrate with the NativeScript Sidekick app that is often suggested as a tool to ease the build/run process of NativeScript applications (there is no way to specify additional parameters for the tns commands that the Sidekick automates, the only options available are switching between debug/release mode), but this is probably better to be left for another question.
Environment files are not yet supported, passing environment variables from build command could be the viable solution for now.
But of course, you may write your own schematics if you like immediate support for environment files.
I did not look into sharing environment files between web and mobile yet - I do like Manoj's suggestion regarding modifying the schematics, but I'll have to cross that bridge when I get there I guess. I might have an answer to your second question regarding Sidekick. The latest version does support "Webpack" build option which seems to pass the --bundle parameter to tns. The caveat is that this option seems to be more sensitive to typescript errors, even relatively benign ones, so you have to be careful and make sure to fix them all prior to building. In my case I had to lock the version of #types/jasmine in package.json to "2.8.6" in order to avoid some incompatibility between that and the version of typescript that Sidekick's cloud solution is using. Another hint is to check "Clean Build" after npm dependency changes are made. Good luck!
I am creating a kbskit for my tcl executable application as follows on Suse :
./kbs.tcl -builddir=85 -r -mk-bi -bi="itcl3.4 itk3.4 iwidgets4.0.2 img1.4.1" install kbskit8.5
cp 85/bin/kbsmk8.5-bi kbsmk8.5-bi-run
./kbsmk8.5-bi sdx.kit wrap sim -runtime kbsmk8.5-bi-run
The application will be used on several flavours of linux like Redhat,Ubuntu etc. I am trying my best to test it myself under many combinations. Neverthless, i would be like to know someone thinks this would/wouldn’t work seamlessly across different platforms since I wont be able to cover all combinations exhaustively.
A Linux/x86 kbskit is at least reasonable to run on that collection of platforms. Unfortunately, the only way to be sure is to try. It should work, but if your script refers to files in a particular location and another platform (or deployment!) puts them elsewhere, then things will fail. The other thing that might go wrong is if there are significant incompatibilities in the small number of system libraries that Tcl uses, especially the C library; I do not know whether such problems exist, but I suspect they're not a major problem in practice.
You can try using the platform package (a standard part of Tcl since at least 8.5) to report what platform you're dealing with. That's the usual level of granularity you need to pay attention to.
package require platform
puts [platform::identify]
Is it possible to control how merge tools recognise similar blocks of code? Particularly meld, but any suggestions of alternative tools also welcome. If it is relevant, I am using mercurial.
I am working on a system which has a code generator generating initial get/set functions and a fairly common situation is two developers have each added a field, and the new get/set functions are generated at the end of the library. When it comes to merging, there is an inevitable merge conflict.
What I would like is for the merge tool to recognise these as separate functions, rather than modified versions of the same function.
Meld at least starts off with a nice enough view, showing the functions added to each version:
Unfortunately, after I pull across the first it, it now thinks the functions have been modified on one system, instead of seeing them as two separate functions. This is also the same merge result as I see initially in KDiff3:
With KDiff3 you can place manual sync marks to force it to consider lines to be equal. See this answer for example and screen shots.
I have a multi-configuration project set up to run FF and IE selenium tests. However, it's not aggregating the test results.
If I look at the Project Page I see this:
If I go into a specific build I see this:
But if I click on one of those specific configuration names I see this:
Is there a way to get these results to aggregate? (I have the aggregate downstream results project configuration checkbox checked)
This is currently a Jenkins bug- Kohsuke Kawaguchi specifically replied to this bug on Aug/31/2011 in the IRC channel (logs - start # [21:54:47]). Here are the work around responses from those two links:
From the Bug page >>
You can workaround this by explicitly specifying the jobs to aggregate, rather than relying on the downstream builds logic, and specifying the matrix axes (in quotes) explicitly - i.e., NonMatrixJob,"MatrixJob/label=l_centos5_x86" - the quotes in case of commas in your axis.
From the IRC Log >>
I did verify that explicitly specifying the list of jobs to aggregate test results from and using the fully qualified job name, including axis, did the trick, but it's a shame that I can't get the auto-discovery from the downstream jobs working.
Which of the hg plug-ins has:
the least hassles
causes the least trouble
is prettiest
Can't claim to have tried a wide variety, but, what's wrong with hg4idea...?
In regards to the "don't use one" response - this is hardly adequate. What if I use my IDE to do a refactoring that renames a file? Without IDE/source control integration, the file rename is made without regards to source control, and then Mercurial (or whatever else) thinks a file went missing and a new one appeared. Then you have to go back to wrangle with the source control to sort things out.
JetBrains seems to have chosen hg4idea-luciad for its upcoming Python editor (PyCharm) and it is now more active than hg4idea
It looks like a leader is on the way :-)
To answer your question: The best IDE PlugIn is don't use on.
I think IDE integration is not necessary when working with a DVCS. When working in a centralized System, it is reasonable for the purpose of automatic check out on edit. However, I like keeping things separate. I don't want my IDE cluttered up. I don't see any benefits in using a plug-in compared to a standalone solution (that I keep running on a second monitor etc. ).
I am fine with TortoiseHG and the command line for more complicated tasks.