I would like to have a kubeflow where, on one of the steps, one can select a value interactively based on intermediate results.
Would this be possible in kubeflow? If so, how would one go about it?
Thanks!
Related
I would like to have my parameters input taken in a horizontal order from Jenkins ui rather than going by its default nature of being vertical.
Attaching the link of the exact question asked before but unresolved.
issue
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 am looking at the opportunities for implementing a data analysis algorithm using Google Cloud Dataflow. Mind you, I have no experience with dataflow yet. I am just doing some research on whether it can fulfill my needs.
Part of my algorithm contains some conditional iterations, that is, continue until some condition is met:
PCollection data = ...
while(needsMoreWork(data)) {
data = doAStep(data)
}
I have looked around in the documentation and as far as I can see I am only able to do "iterations" if I know the exact number of iterations before the pipeline starts. In this case my pipeline construction code can just create a sequential pipeline with fixed number of steps.
The only "solution" I can think of is to run each iteration in separate pipelines, store the intermediate data in some database, and then decide in my pipeline construction whether or not to launch a new pipeline for the next iteration. This seems to be an extremely inefficient solution!
Are there any good ways to perform this kind of additional iterations in Google cloud dataflow?
Thanks!
For the time being, the two options you've mentioned are both reasonable. You could even combine the two approaches. Create a pipeline which does a few iterations (becoming a no-op if needsMoreWork is false), and then have a main Java program that submits that pipeline multiple times until needsMoreWork is false.
We've seen this use case a few times and hope to address it natively in the future. Native support is being tracked in https://github.com/GoogleCloudPlatform/DataflowJavaSDK/issues/50.
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.