The 'name' attribute must be unique for each radioBlock. A solution that
worked for me (in a different case, such as in JENKINS-5028
https://issues.jenkins-ci.org/browse/JENKINS-5028 ) was to add a unique
generated string to the name attribute. In my case I concatenated
${instance.hashCode()} to
I've created a pull request https://github.com/jenkinsci/jenkins/pull/925with
Jenkins-Core changes included. There is a request to test the changes
against CloudBees Folders
Pluginhttp://jenkins-enterprise.cloudbees.com/docs/user-guide-bundle/folder.html
which
is allowed only for Enterprise
You can get this plugin for Free, just need a cloudbees account, installing
cloudbees free plugins plugin from standard Update Center
You also can use MockFolder to setup unit tests to cover your changes
2013/8/27 Stanislav Bashkirtsev stanislav.bashkirt...@gmail.com
I've created a pull
I always just do
name=${h.generateId()}.name
since the data-binding only pays attention to the bit after the last `.`
Also ensures that when adding repeatables you are getting unique Ids
On 27 August 2013 13:01, sophpc or...@hp.com wrote:
The 'name' attribute must be unique for each
Sorry, but your solution breaks the radio block. All the buttons in a block
must have the same name in order to be grouped into a single selection.
Since /generateId()/ creates a unique id for each radio button, you just get
multiple radio blocks (each containing a single button)
--
View this
Thanks a lot, I've enabled Free Plugins and that worked.
Вівторок, 27 серпня 2013 р. 16:37:22 UTC+4 користувач nicolas de loof
написав:
You can get this plugin for Free, just need a cloudbees account,
installing cloudbees free plugins plugin from standard Update Center
You also can use
ahh I'm just being too short-handed...
Do this at the level where you start putting all the radio options
j:set var=radioId value=${h.generateId}/
Then for each radio
name=${radioId}.fieldname
That will give you what you are after.
On 27 August 2013 15:31, sophpc or...@hp.com wrote:
Sorry,
I was off for holidays. I just deployed it : https://ci.exoplatform.org/
I'll tell you in incoming days if it has a good behavior
At least it seems I don't have anymore all issues with blanck screens I had
since the introduction of the lazy loading that enforced me to keep the
1.480.3 up until
Hello,
could anybody revise:
https://github.com/jenkinsci/maven-hpi-plugin/pull/6
It makes the name of the InjectedTest configurable (e.g. for running
it during integration-test phase).
Regards Mirko
--
http://illegalstateexception.blogspot.com/
https://github.com/mfriedenhagen/
Anything stopping us from releasing 1.509.3?
/Domi
On 27.08.2013, at 20:33, Arnaud Héritier aherit...@gmail.com wrote:
I was off for holidays. I just deployed it : https://ci.exoplatform.org/
I'll tell you in incoming days if it has a good behavior
At least it seems I don't have anymore all
It seems that sometimes the dashboard takes some time to load
Is there a cache to avoid the lazy loading issue ?
On Tue, Aug 27, 2013 at 9:48 PM, domi d...@fortysix.ch wrote:
Anything stopping us from releasing 1.509.3?
/Domi
On 27.08.2013, at 20:33, Arnaud Héritier aherit...@gmail.com
On Tue, Aug 27, 2013 at 5:50 PM, Arnaud Héritier aherit...@gmail.com wrote:
It seems that sometimes the dashboard takes some time to load
Investigate with thread dumps and file as needed; could be
lts-candidate for a future LTS release.
--
You received this message because you are subscribed
Hi,
I have written a plugin (
https://wiki.jenkins-ci.org/display/JENKINS/Jenkins-Reviewbot) that picks a
diff from review and builds it with the patch plugin, reporting the status
back on the review. Feedback (and help) is most welcome :-)
Currently it's only half-way from what I want the
13 matches
Mail list logo
