Related
I am using jenkins with the pipeline plugin to build my microservices based application. This works basically, but there is no way to get a good overview which services have been build last for which branch and what the result was. Even the new Blue UI falls short :-(
I just want to have the name + last builds results for the pipelines to be able to see if something is going wrong somewhere.
I have searched for plugins which might help here but I had no luck.
Has someone solved this in some way already?
I don't want to spend my time writing my own visualization, but I am beginning to realize that this will be the way to go. :-/
If nothing like this exists does someone know a good source to start to use the jenkins api for this kind of visualization?
You can do that using https://wiki.jenkins-ci.org/display/JENKINS/Dashboard+View
It allows you to add a job list and specify the jobs to be included using a regular expression. Hence, new jobs for feature branches should appear automatically.
I guess, this will be a one end to end product for you. I have been using it from the last 6 Months.
This is much better than the other Dashboards.
Hygieia Dashboard
Is it possible to trigger Jenkins builds on nodes with an unknown label value based on a build's parameter?
I've got a job for building that allows our devs to do just about any kind of build they want, including specified hardware to build against. The problem is that this list of HW is always changing, and I'm trying to stamp out tech debt. I would like it to be where the only necessity is a hardware-specific node having a label the devs know about, and them using a string parameter to match that node label to build against that hardware. They may have labels like, Gen1, Gen2, ProtoXYZ, who knows, you know? It evolves, constantly.
I've seen a few similar questions, but for this one, there isn't a solution, and for this one, I'm not actually sure what's going on here. I've yet to touch Groovy, and I'm trying to do as much as I can with plugins and existing Jenkins functionality.
That doesn't mean I won't do Groovy scripts -- it's just more that I'd like to not obfuscate the process with custom scripts.
Edit:
I'm still testing it, but it looks like this one-liner Groovy script with the plugin, "Groovy Label Assignment" seems to work, but I will check back within the hour:
binding.getVariables().get("HARDWARE");
Where HARDWARE is a parameter that is set by a job parameter. The one thing I'm left to check is whether I can mix and match known and unknown labels with this functionality, e.g., a small drop-down box with known choices, but one choice essentially being "Other, please enter".
Edit: I've been so frazzled that I googled my own previously answered question, answered by myself no less xD I've changed the title to match something more search-engine friendly. Original title was,
Is it possible to trigger Jenkins builds on nodes with an unknown
label value based on a build parameter?
Okay, so this is cool. Yes, this is possible. I did use a Groovy script, but it was a one-liner working in conjunction with a plugin, so not much overheard to keep track of, which I considered acceptable.
First thing's first, using the plugin's site's instructions, I tried this out:
binding.getVariables().get("HARDWARE");
HARDWARE is a job parameter. It's actually a drop-down box, e.g., a Choice Parameter, from that plugin. To invoke this plugin, there's a box to check after installing it called,
Groovy script to restrict where this project can be run
It works like in conjunction with one of my parameters:
Choice1
Choice2
Choice3
${CUSTOM_CHOICE}
In the job, I set ${CUSTOM_CHOICE}'s parameter before I set HARDWARE. This allows HARDWARE to inherit the value of ${CUSTOM_CHOICE} if it exists. It's not idiot-proof, but it gives my devs the flexability to use some well-known choices, or go crazy and experiment. I've verified that this functionality works.
I'm looking for an alternative to FileMaker Pro. I've been playing with a trial for a week now.
I'm looking for a rapid application development platform for small relational databases to run on iOS and OS X
Things I like about FM
Can make reasonable looking layouts quite quickly.
Can access the database from an iPad with Filemaker Go.
Things I don't like about FM
EVERYTHING takes a half a dozen clicks. In particular constructing a script with mouse clicks is painful.
The number of modal dialog boxes is astounding. It is routine to have them layered 3 deep.
Syntax is verbose. Set Variable [ $name Value:value ] Some of the examples start to look like excel formulas. (Excel is a write only language....) Or COBOL.
Near as I can figure variable scope is either local or global. If a script calls a script, you must call it with any local variables you want it to have access to.
Debugging is very difficult in the FM Pro version.
Doesn't seem to be any provision for building a library of functions in a single file.
No clear and obvious guide to how to document your database so that it can be maintained.
No clear and obvious way to print out all your scripts.
No clear and obvious way to print out a calling tree/dependency tree.
No clear guide to best practices.
The short answer is: Despite it's shortcomings (and I'll admit it has many), FileMaker is still the best rapid-development platform for OS X and iOS (and Windows, for that matter). The closest second-place (for OS X/iOS) I can think of would be Cocoa/Cocoa Touch with Core Data with Ruby on Rails for a web interface a distant third.
Having said that, I can offer a few tips for some of your complaints:
If you're a keyboard-centric person like myself, turn on Full Keyboard Access (in the Keyboard System Preference within the Shortcuts tab). This will allow you to tab through all of the controls, such as buttons, which makes it much easier to select deep dialog options from the keyboard. For example, when building a script, you can use the tab key to focus on the list of script steps, then type a few letters of the step you want, which will highlight it, and press return, which will add it to the script. Then, while a script step in the script is highlighted, you can use Ctrl-Up and Ctrl-Down to move the step up and down in the execution order.
Script variables, both local and global, can be set within any calculation. For example, if you're capturing a primary key value to a local variable and you already have an If script step, you can do the capture within the If script step.
If[ Let( [ $record_id = Table::ID ]; not IsEmpty( $record_id ) ) ]
Similarly, if you have a number of Set Variable script steps in a row, you can combine them into one:
Set Variable[ $? Value:Let( [ $var1 = 1; $var2 = "two" ] ) "" ]
This sets the $? variable to an empty string, but has the side effect of also setting $var1 and $var2.
You're correct that variables are either local to a script (or calculation) or global to the file. If you want to share information between scripts, parameters are the solution. For my personal solution for sending multiple parameters to a script, read my article on Multiple FileMaker Script Parameters.
If you're going to do any amount of custom development with FileMaker, you really want to get FileMaker Pro Advanced, which, inaddition to a step-level debugger, offers the ability to create custom menus and, my personal favorite, custom functions. Using custom functions (which can easily be brought from one file to another), you can built a complex library of functions.
To print out all of your scripts, open Manage Scripts, select all of the scripts with Cmd-A and click the print button on the bottom right of the window.
For script dependencies, look into BaseElements, a FileMaker-based solution for documenting FileMaker systems.
While there's no standard "best practices" across the board, and because of how FileMaker organizes its objects, documentation is often found in various places (script comments, calculation comments, field comments), there are many ways to build a system in FileMaker so that you increase its maintainability. Unlike Objective-C or PHP, where you can be fairly certain where the comment for something will be (either in the declaration or at its first use), FileMaker is more flexible. The important idea behind "best practices" and documentation, in my opinion, is consistency. If you comment a field by using the field comments, always comment fields that way, don't comment calculation fields within the calculation or use dummy validation to put comments in a calculation there.
If you're looking for one guide (but not the only guide) for best practices, check out FileMaker Coding Standards. I use some of those guidelines, and others are my own that have evolved over time.
Finally, if you're looking for generally great material on how to get the most from FileMaker, check out FileMaker Magazine, published by one of the people involved with the FileMaker Coding Standards site.
The truth is, if you're coming from some more conventional development platform, FileMaker is going to take a bit of getting used to. I've been using it for over 20 years, so I'll admit it's probably difficult for me to completely empathize with that situation. But if you give it a bit of a chance, I think you'll find that there's no other platform available that can build complex database systems for OS X and iOS so quickly.
Filemaker takes a lot of getting used to, it's very different to SQL or any of the mainstream taught languages so if you have done some training you will need to re-think how to get to the same end goal.
If you are serious about it then get Filemaker Pro Advanced v14 and that should fix some of your GUI editing issues and join developer.filemaker.com and do the training course that you can download from there.
Once doing that and getting some experience you will find Filemaker is very RAD. Also there IS a way to get around any shortcomings, everything is possible in Filemaker.
As for passing multiple parameters to a script a quick and easy way to do it for 99.5% of cases is to do this:
Calling the script - In the parameters box separate your parameters with a carraige return like so: "parameter 1" & "¶" & "parameter 2" & "¶" & "parameter 3" etc.
In your receiving script use GetValue(get(scriptparameter),1) for parameter 1, 2 for 2, etc.
This technique won't work when you are trying to pass text with carraige returns but that is the exception.
In JIRA a resolved issue can have different resolutions: e.g. Won't Fix, Cannot Reproduce, Fixed etc. I had been using JIRA without Greenhopper and using these resolutions was part of the workflow.
Now I'm using JIRA+Greenhopper with Kanban boards and I'm trying to extend the workflow to have few steps associated with the Resolved step:
In QA which is Status:Resolved,Resolution:Done;
Won't Fix which is Status:Resolved,Resolution:Done;
Backlog which is Status:Resolved,Resolution:Backlog;
etc;
When trying to edit the workflow I learned that it is not possible to have two steps that correspond to one status (Resolved). Is this the case?
At the moment it actually is not possible to set the issue to any resolution different than Done as
the 'Resolve' button is not available on the issue screens (I already asked here about the missing button).
I have tried to set up a new transition which would move the issue into Status:Resolved, Resolution:Won't Fix but I'm hitting the problem that for active workflows if there are no outgoing transitions already defined you cannot create new ones.
Questions:
Is it possible possible to map two workflow steps to one status? Am I missing something and the Won't Fix, Cannot reproduce resolutions don't fit into the Greenhopper way of thinking?
I recommend creating a JIRA workflow from scratch and provide detailed steps in Practical JIRA Administration (O'Reilly). I also recommend having a 1:1 mapping of JIRA step name to status name, and JIRA doesn't do 2:1 mapping. I think you probably want to create new statuses for your workflow, e.g. In QA.
The system resolution field is designed as a kind of sub-status for one, maybe two, statuses. People usually use it just with Closed.
I'm using SpecFlow to do some BDD-style testing. Some of my features are UI tests, so they use WatiN. Some aren't UI tests, so they don't.
At the moment, I have a single StepDefinitions.cs file, covering all of my features. I have a BeforeScenario step that initializes WatiN. This means that all of my tests start up Internet Explorer, whether they need it or not.
Is there any way in SpecFlow to have a particular feature file associated with a particular set of step definitions? Or am I approaching this from the wrong angle?
There is a simple solution to your problem if you use tags.
First tag you feature file to indicate that a particular feature needs WatiN like that:
Feature: Save Proportion Of Sample Pool Required
As an <User>
I want to <Configure size of the Sample required>
so that <I can advise the deployment team of resourcing requirments>.
#WatiN
Scenario: Save valid sample size mid range
Given the user enters 10 as sample size
When the user selects save
Then the value is stored
And then decorate the BeforeScenario binding with an attribute that indicates the tag:
[BeforeScenario("WatiN")]
public void BeforeScenario()
{
...
}
This BeforeScenario method will then only be called for the features that use WatiN.
Currently (in SpecFlow 1.3) step-definitions are global and cannot be scoped to particular features.
This is by design to have the same behavior as Cucumber.
I asked the same question on the cucumber group:
http://groups.google.com/group/cukes/browse_thread/thread/20cd7e1db0a4bdaf/fd668f7346984df9#fd668f7346984df9
The baseline is, that the language defined by all the feature files should also be global (one global behavior of the whole application). Therefore scoping definitions to features should be avoided. Personally I am not yet fully convinced about this ...
However your problem with starting WatiN only for scenarios that need UI-Integration can be solved in two different ways:
Tags and tagged hooks: You can tag your scenarios (i.e with #web) and define ina BeforeScenario-Hook that only should run for scenarios with a certain tag (i.e. [BeforeScenario("web")]). See the Selenium integration in our BookShop example: http://github.com/techtalk/SpecFlow-Examples/blob/master/ASP.NET-MVC/BookShop/BookShop.AcceptanceTests.Selenium/Support/SeleniumSupport.cs
We often completely separate scenarios that are bound to the UI and scenarios that are bound to a programmatic API (i.e controller, view-model ...) into different projects. We tried to illustrate this in our BookShop example: http://github.com/techtalk/SpecFlow-Examples/tree/master/ASP.NET-MVC/BookShop/ .
Check this out (new feature in SpecFlow 1.4): https://github.com/techtalk/SpecFlow/wiki/Scoped-Bindings
I originally assumed that a step file was associated with a particular feature file. Once I realized this was not true it helped me to improve all my SpecFlow code and feature files. The language of my feature files is now less context depended, which has resulted in more reusable step definitions and less code duplication. Now I organize my step files according to general similarities and not according to which feature they are for. As far as I know there is no way to associate a step with a particular feature, but I am not a SpecFlow expert so don't take my word for it.
If you still would like to associate your step files with a particular feature file, just give them similar names. There is no need for it to be forced to only work for that feature even if the step code only makes sense for that feature. This is because even if you happen to create a duplicate step for a different feature, it will detect this as an ambiguous match. The behavior for ambiguous matches can be specified in an App.config file. See
http://cloud.github.com/downloads/techtalk/SpecFlow/SpecFlow%20Guide.pdf
for more details the about App.config file. By default ambiguous matches are detected and reported as an error.
[edit]:
Actually there is a problem with working this way (having step files associated with feature files in your mind only). The problem comes when you add or modify a .feature file and use the same wording you have used before, and you forget to add a step for it, but you don't notice this because you already created a step for that wording once before, and it was written in a context sensitive manner. Also I am no longer convinced of the usefulness of not associating step files with feature files. I don't think most clients would be very good at writing the specification in a context independent manner. That is not how we normally write or talk or think.
Solution for this is to implement Tags & Scoped Binding with the test scenario which is related to Web or related to Controller / Core logic in code.
And drill down the scope for each scenario to any of the below mentioned Before / After execution
BeforeTestRunScenario
BeforeFeature
BeforeScenario
BeforeScenarioBlock
BeforeStep
AfterStep
AfterScenarioBlock
AfterScenario
AfterFeature
AfterTestRunScenario
Also consider using implementation-agnostic DSL along with implementation-specific step definitions. For example, use
When I search for 'Barbados'
instead of
`When I type 'Barbados' in the search field and push the Search button
By implementing multiple step definition assemblies, the same Scenario can execute through different interfaces. We use this approach to test UI's, API's, etc. using the same Scenario.