[JIRA] [multijob-plugin] (JENKINS-29424) Ability to filter jobs in multijob view
Title: Message Title Vladimir Sitnikov created an issue Jenkins / JENKINS-29424 Ability to filter jobs in multijob view Issue Type: New Feature Assignee: Unassigned Components: multijob-plugin Created: 14/Jul/15 4:22 PM Priority: Major Reporter: Vladimir Sitnikov I use several multijobs and certain jobs are invoked at certain phases of a parent multijob. Current multijob view shows all the jobs, so it would be nice to have a regexp selector of jobs included into multijob view. Add Comment
[JIRA] [job-dsl-plugin] (JENKINS-27050) Parameterized seed job is automatically triggered after change
Title: Message Title Vladimir Sitnikov commented on JENKINS-27050 Re: Parameterized seed job is automatically triggered after change Christoph Burgmer, can you please give a hint how you did debug the source of the trigger? I'm running into the same Template has changed, however I see no obvious reason for those triggers. If only I had a job name that causes those triggers. Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [gitlab-hook-plugin] (JENKINS-29283) Allow cloning job trees when creating job via gitlab web hook
Title: Message Title
Vladimir Sitnikov Sitnikov created an issue
Jenkins / JENKINS-29283
Allow cloning job trees when creating job via gitlab web hook
Issue Type:
Bug
Assignee:
Javier Palacios
Components:
gitlab-hook-plugin
Created:
08/Jul/15 7:55 AM
Priority:
Major
Reporter:
Vladimir Sitnikov Sitnikov
Currently, the hook copies the job as is and just alters git urls.
I wish I could modify the job in accordance with the branch (e.g. via Job DSL plugin or JobCopy plugin).
For instance: I use MultiJob plugin to create a build pipeline. MultiJob requires names of the child jobs be in literal. It does not allow to specify build-$ {branch}
in the definition of phase job. So I would like to be able to clone those child jobs with new names and wire the whole thing.
A workaround I see is to use parameterized with branch jobs for each step, however that messes up the statistics. For instance, build job builds different branches at different times, so it is bad for any kind of statistics.
[JIRA] [gitlab-hook-plugin] (JENKINS-29283) Allow cloning job trees when creating job via gitlab web hook
Title: Message Title
Vladimir Sitnikov Sitnikov updated an issue
Jenkins / JENKINS-29283
Allow cloning job trees when creating job via gitlab web hook
Change By:
Vladimir Sitnikov Sitnikov
Currently,thehookcopiesthejobasisandjustaltersgiturls.IwishIcouldmodifythejobinaccordancewiththebranch(e.g.via[JobDSL|https://wiki.jenkins-ci.org/display/JENKINS/Job+DSL+Plugin]pluginor[JobCopyplugin|https://wiki.jenkins-ci.org/display/JENKINS/Jobcopy+Builder+plugin]).Forinstance:Iuse[MultiJob|https://wiki.jenkins-ci.org/display/JENKINS/Multijob+Plugin]plugintocreateabuildpipeline.MultiJobrequiresnamesofthechildjobsbeinliteral.Itdoesnotallowtospecifybuild-$ \ {branch \ }inthedefinitionofphasejob.SoIwouldliketobeabletoclonethosechildjobswithnewnamesandwirethewholething.AworkaroundIseeistouseparameterizedwithbranchjobsforeach step buildphase ,howeverthatmessesupthestatistics.Forinstance, build compiletheproject jobbuildsdifferentbranchesatdifferenttimes,soitisbadforanykindofstatistics.
Add Comment
This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265)
--
You received this message because you are subscribed to the Google Groups Jenkins Issues group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[JIRA] [gitlab-hook-plugin] (JENKINS-29317) Trigger only autogenerated jobs, not all the jobs for given git url
Title: Message Title
Vladimir Sitnikov Sitnikov created an issue
Jenkins / JENKINS-29317
Trigger only autogenerated jobs, not all the jobs for given git url
Issue Type:
Bug
Assignee:
Javier Palacios
Components:
gitlab-hook-plugin
Created:
09/Jul/15 3:49 PM
Priority:
Critical
Reporter:
Vladimir Sitnikov Sitnikov
Currently gitlab-hook-plugin searches all the jobs that match given repository url.
In fact, I use multijob configuration like the following:
MainJob -- uses git configuration so gitlab-hook-plugin can find clone start it
* Phase 1: compile job -- uses git to fetch project sources
* Phase 2: deploy
* Phase 3: fast tests -- uses git to fetch tests
...
Current gitlab-hook-plugin triggers all the jobs, not just the main one.
In my installation I've modified plugins\gitlab-hook\WEB-INF\classes\models\use_cases\process_commit.rb }} as follows (added {{ (project.description.match /#{settings.description}/)) so it triggers only jobs with autogenerated description:
def get_projects_to_process(details)
projects = @get_jenkins_projects.matching_uri(details)
if projects.any?
if settings.automatic_project_creation?
projects.select! do |project|
[JIRA] [gitlab-hook-plugin] (JENKINS-29318) Support deleting multiple jobs on branch delete
Title: Message Title Vladimir Sitnikov created an issue Jenkins / JENKINS-29318 Support deleting multiple jobs on branch delete Issue Type: New Feature Assignee: Javier Palacios Components: gitlab-hook-plugin Created: 09/Jul/15 4:45 PM Priority: Major Reporter: Vladimir Sitnikov A build configuration for a single branch can easily consist of more than one job. It would be nice if gitlab-hook could delete all the parts on branch removal. I think call parametrized job on branch delete would do the trick, so each project can create relevant cleanup job. Does that make sense? Add Comment
[JIRA] [gerrit-trigger-plugin] (JENKINS-28168) gerrit-trigger used cpu 100%
Title: Message Title Vladimir Sitnikov commented on JENKINS-28168 Re: gerrit-trigger used cpu 100% This is a JDK bug: https://bugs.openjdk.java.net/browse/JDK-8028627 Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [gitlab-hook-plugin] (JENKINS-29283) Allow cloning job trees when creating job via gitlab web hook
Title: Message Title Vladimir Sitnikov commented on JENKINS-29283 Re: Allow cloning job trees when creating job via gitlab web hook Finally I ended up with the following setup: 1) seed job calls jobcopy plugin to create jobs as required and schedules the proper job for execution 2) gitlab-hook triggers only seed job no matter which branch is triggered In that setup, gitlab-hook still does not work out-of-the-box since it tries to trigger all the jobs (see JENKINS-29317). Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [testng-plugin] (JENKINS-30285) TestNG plugin is unable to parse << in results xml
Title: Message Title Vladimir Sitnikov created an issue Jenkins / JENKINS-30285 TestNG plugin is unable to parse << in results xml Issue Type: Bug Assignee: Nalin Makar Components: testng-plugin Created: 03/Sep/15 4:14 PM Priority: Major Reporter: Vladimir Sitnikov The following part of testng-results.xml makes testng plugin to fail parsing: ... The message is as follows: 00:34:42.839 Failed to parse XML: unexpected character in markup < (position: TEXT seen ...e same size expected [1] but found [2]>> matches exclude regexp <<... @175:313) 00:34:42.839 org.xmlpull.v1.XmlPullParserException: unexpected character in markup < (position: TEXT seen ...e same size expected [1] but found [2]>> matches exclude regexp <<... @175:313) 00:34:42.839 at org.xmlpull.mxp1.MXParser.nextImpl(MXParser.java:1261) 00:34:42.839 at org.xmlpull.mxp1.MXParser.nextToken(MXParser.java:1100) 00:34:42.839 at hudson.plugins.testng.parser.ResultsParser.parse(ResultsParser.java:154) 00:34:42.839 at hudson.plugins.testng.TestNGTestResultBuildAction.loadResults(TestNGTestResultBuildAction.java:120) 00:34:42.839 at hudson.plugins.testng.Publisher.perform(Publisher.java:126) 00:34:42.839 at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:20) 00:34:42.839
[JIRA] [gitlab-plugin] (JENKINS-35258) [Gitlab plugin] ci-skip and author should use the latest commit, not the first one from the push event
Title: Message Title
Vladimir Sitnikov updated an issue
Jenkins / JENKINS-35258
[Gitlab plugin] ci-skip and author should use the latest commit, not the first one from the push event
Change By:
Vladimir Sitnikov
Gitlab plugin uses the first commit to check if "\[ci-skip\]" is present,https://github.com/jenkinsci/gitlab-plugin/blob/c27af273327e1660d619a27045f0dd301af68067/src/main/java/com/dabsquared/gitlabjenkins/trigger/handler/push/PushHookTriggerHandlerImpl.java#L32-L35It causes some CIs being skipped for no reason.Impact: when rebasing feature branches, CI is skipped for no reason, causing developers to struggle (they have absolutely no clue why CI has "broken") Current workaround is {{git commit --amend && git push -f}} Consider the following:1) feature_foo is branched from master and pushed to gitlab -> CI is triggered as expected2) {{\[ci-skip\]}} commit is added to master -> CI is skipped3) git checkout feature_foo && git rebase master && git push -> CI is *skipped* since push event for branch feature_foo includes all the commits, including {{\[ci-skip\]}} commit that was present in master branch before rebase.I think only the latest commit should be used to tell if {{\[ci-skip\]}} is present or not. Does it make sense? A similar issue is around retrievePushedBy (the first commit is likely to be the least relevant one):https://github.com/jenkinsci/gitlab-plugin/blob/c27af273327e1660d619a27045f0dd301af68067/src/main/java/com/dabsquared/gitlabjenkins/trigger/handler/push/PushHookTriggerHandlerImpl.java#L89Just in case:Jenkins 2.6Gitlab plugin 1.2.3Git plugin 2.4.4Java 1.8u92Gitlab 8.7.5
Add Comment
This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265)
[JIRA] [gitlab-plugin] (JENKINS-35258) [Gitlab plugin] ci-skip and author should use the latest commit, not the first one from the push event
Title: Message Title
Vladimir Sitnikov updated an issue
Jenkins / JENKINS-35258
[Gitlab plugin] ci-skip and author should use the latest commit, not the first one from the push event
Change By:
Vladimir Sitnikov
Gitlab plugin uses the first commit to check if "\[ci-skip\]" is present,https://github.com/jenkinsci/gitlab-plugin/blob/c27af273327e1660d619a27045f0dd301af68067/src/main/java/com/dabsquared/gitlabjenkins/trigger/handler/push/PushHookTriggerHandlerImpl.java#L32-L35It causes some CIs being skipped for no reason.Impact: when rebasing feature branches, CI is skipped for no reason, causing developers to struggle (they have absolutely no clue why CI has "broken")Consider the following:1) feature_foo is branched from master and pushed to gitlab -> CI is triggered as expected2) {{\[ci-skip\]}} commit is added to master -> CI is skipped3) git checkout feature_foo && git rebase master && git push -> CI is *skipped* since push event for branch feature_foo includes all the commits, including {{\[ci-skip\]}} commit that was present in master branch before rebase.I think only the latest commit should be used to tell if {{\[ci-skip\]}} is present or not.A similar issue is around retrievePushedBy (the first commit is likely to be the least relevant one):https://github.com/jenkinsci/gitlab-plugin/blob/c27af273327e1660d619a27045f0dd301af68067/src/main/java/com/dabsquared/gitlabjenkins/trigger/handler/push/PushHookTriggerHandlerImpl.java#L89 Just in case:Jenkins 2.6Gitlab plugin 1.2.3Git plugin 2.4.4Java 1.8u92Gitlab 8.7.5
Add Comment
This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265)
[JIRA] [gitlab-plugin] (JENKINS-35258) [Gitlab plugin] ci-skip and author should use the latest commit, not the first one from the push event
Title: Message Title Vladimir Sitnikov created an issue Jenkins / JENKINS-35258 [Gitlab plugin] ci-skip and author should use the latest commit, not the first one from the push event Issue Type: Bug Assignee: Robin Müller Components: gitlab-plugin Created: 2016/Jun/01 9:52 AM Priority: Major Reporter: Vladimir Sitnikov Gitlab plugin uses the first commit to check if "[ci-skip]" is present, https://github.com/jenkinsci/gitlab-plugin/blob/c27af273327e1660d619a27045f0dd301af68067/src/main/java/com/dabsquared/gitlabjenkins/trigger/handler/push/PushHookTriggerHandlerImpl.java#L32-L35 It causes some CIs being skipped for no reason. Impact: when rebasing feature branches, CI is skipped for no reason, causing developers to struggle (they have absolutely no clue why CI has "broken") Consider the following: 1) feature_foo is branched from master and pushed to gitlab -> CI is triggered as expected 2) [ci-skip] commit is added to master -> CI is skipped 3) git checkout feature_foo && git rebase master && git push -> CI is skipped since push event for branch feature_foo includes all the commits, including [ci-skip] commit that was present in master branch before rebase. I think only the latest commit should be used to tell if [ci-skip] is present or not. A similar issue is around retrievePushedBy (the first commit is likely to be the least relevant one):
[JIRA] [core] (JENKINS-35203) Use ConcurrentSkipListMap instead of CopyOnWriteMap
Title: Message Title Vladimir Sitnikov moved an issue Jenkins / JENKINS-35203 Use ConcurrentSkipListMap instead of CopyOnWriteMap Change By: Vladimir Sitnikov Project: Infrastructure Jenkins Key: INFRA JENKINS - 724 35203 Workflow: classic default workflow JNJira Component/s: core Component/s: core Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from
[JIRA] [gitlab-hook-plugin] (JENKINS-29318) Support deleting multiple jobs on branch delete
Title: Message Title Vladimir Sitnikov commented on JENKINS-29318 Re: Support deleting multiple jobs on branch delete This is an additional feature to JENKINS-29317. In other words, it might make sense to configure things like "trigger jobs A,B on push, C,D on delete, etc". However, I would be fine if the same job is triggered on push/delete provided there is a parameter that identifies the source event (push, deleted branch, etc). Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [gitlab-hook-plugin] (JENKINS-29283) Allow cloning job trees when creating job via gitlab web hook
Title: Message Title Vladimir Sitnikov commented on JENKINS-29283 Re: Allow cloning job trees when creating job via gitlab web hook Finally, I gave up with Job Copy, job cloning, etc, so this issue can probably be closed. Job cloning has too much constraints. I ended up with using Job DSL for programmatic job creation. The case is explained here: https://issues.jenkins-ci.org/browse/JENKINS-29317?focusedCommentId=245505=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-245505 Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [gitlab-hook-plugin] (JENKINS-29317) Trigger only autogenerated jobs, not all the jobs for given git url
Title: Message Title Vladimir Sitnikov commented on JENKINS-29317 Re: Trigger only autogenerated jobs, not all the jobs for given git url Javier Palacios, my case is as follows: 1) I have a project at Gitlab. Suppose it is named "ProjectFoo". 2) I want each branch to spawn a dedicated Jenkins job. The intention is as follows: each developer works in his/her own branch, thus having separate Jenkins jobs helps a lot. However, the build process itself is not that simple. Basically it includes several stages: S1) Fetch & compile project S2) Prepare database (each test is to be executed in a clean environment, thus each job execution gets its own database schema) S3) Deploy the code (run installation SQL scripts, etc, etc) S4) Execute fast tests (if they fail, no need to run full suite) S5) Execute full suite of tests (here additional DB instances are provisioned to test against different DB versions, etc) S6) Uninstall (to test uninstall) I think it is somewhat typical scenario for integration tests. In order to simplify management of those integration jobs, I use Job DSL plugin. In other words, I have a "seed job" that generates all those S1, S2, ..., S3 given the input parameters like "branch name", "DB versions to test", etc. The "seed job" has just a single step: "invoke groovy script". Job management via groovy scripts turned out to be very efficient. So my end-to-end is: E1) A developer pushes commit to Gitlab E2) Gitlab notifies Jenkins. Here only seed job should be triggered. E3) Seed job fetches project sources, figures out the proper set of integration jobs, creates/updates as required, then triggers the actual integration testing. The problem is at step E2 my Jenkins server has lots of jobs with given GIT project URL. For each project I have exactly one seed job, so I do not want to trigger all of them. Does that make sense? Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265)
[JIRA] [gitlab-hook-plugin] (JENKINS-29317) Trigger only autogenerated jobs, not all the jobs for given git url
Title: Message Title
Vladimir Sitnikov edited a comment on JENKINS-29317
Re: Trigger only autogenerated jobs, not all the jobs for given git url
I have lots of jobs that access git for different reasons:0) "seed job" to get "integration configuration"1) compile job to compile the project2) test job to get test sourcesetc, etc.In other words, what I want from Gitlab-Jenkins integration is that the plugin triggers ONLY the seed job.I'm fine to set " build trigger job in case of gitlab push" kind of flag on a seed job.{quote} connection was done with the standard jenkins triggering{quote}Multijob connection enables to have:1) Single status view of each step2) Single "stop all" button3) Nice "cleanup if anything went wrong" steps4) etc, etc.However multijob stuff is completely irrelevant for the particular issue. The issue is to have an ability to limit the set of triggered jobs. Why trigger all the jobs with given url?
Add Comment
This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265)
--
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[JIRA] [gitlab-hook-plugin] (JENKINS-29317) Trigger only autogenerated jobs, not all the jobs for given git url
Title: Message Title Vladimir Sitnikov commented on JENKINS-29317 Re: Trigger only autogenerated jobs, not all the jobs for given git url I have lots of jobs that access git for different reasons: 0) "seed job" to get "integration configuration" 1) compile job to compile the project 2) test job to get test sources etc, etc. In other words, what I want from Gitlab-Jenkins integration is that the plugin triggers ONLY the seed job. I'm fine to set "build job in case of gitlab push" kind of flag on a seed job. connection was done with the standard jenkins triggering Multijob connection enables to have: 1) Single status view of each step 2) Single "stop all" button 3) Nice "cleanup if anything went wrong" steps 4) etc, etc. However multijob stuff is completely irrelevant for the particular issue. The issue is to have an ability to limit the set of triggered jobs. Why trigger all the jobs with given url? Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [gitlab-hook-plugin] (JENKINS-29317) Trigger only autogenerated jobs, not all the jobs for given git url
Title: Message Title Vladimir Sitnikov commented on JENKINS-29317 Re: Trigger only autogenerated jobs, not all the jobs for given git url It is acceptable to set the webhook url to something like http://jenkins.url/gitlab/build_now/seedproject? I think so. However, in the long run "dumb configuration of webhook" + "smart configuration at jenkins side" might be better. so it should be hard to just trigger seedproject in that case. You mean "it should not be hard to trigger in that case", don't you? Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-35258) [Gitlab plugin] ci-skip and author should use the latest commit, not the first one from the push event
Title: Message Title Vladimir Sitnikov commented on JENKINS-35258 Re: [Gitlab plugin] ci-skip and author should use the latest commit, not the first one from the push event Wonderful. Will check. Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-26971) looking at failed TestNG result causes an exception
Title: Message Title
Vladimir Sitnikov commented on JENKINS-26971
Re: looking at failed TestNG result causes an exception
{quote}there should be a button that says "Downgrade to X.X". {quote} The sad thing is 1.13 is not compatible with "pipeline"
Add Comment
This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e)
--
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-51341) Suite name is not shown on the main page and method results page
Title: Message Title Vladimir Sitnikov created an issue Jenkins / JENKINS-51341 Suite name is not shown on the main page and method results page Issue Type: Bug Assignee: Nalin Makar Components: testng-plugin Created: 2018-05-15 14:23 Priority: Major Reporter: Vladimir Sitnikov I use TestNG for integration testing, and I happen to use the same test class/method across multiple test suites. That is I have lots of xml files that have different parameter values. The problem is current results page lists package.Class.method multiple times, and it is extremely hard to tell which suites actually failed. I wish the results page shown not just package, class, and method names, but test suite names (and/or "test" names that come from
[JIRA] (JENKINS-51341) Suite name is not shown on the main page and method results page
Title: Message Title Vladimir Sitnikov commented on JENKINS-51341 Re: Suite name is not shown on the main page and method results page Nalin Makar, As far as I can see, plugin wiki page is marked with adopt-this-plugin. Is that up to date? Are you actively maintaining the plugin? I think I can implement the fix on my own, however it is not clear what would be the release procedure. Add Comment This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-51341) Suite name is not shown on the main page and method results page
Title: Message Title Vladimir Sitnikov commented on JENKINS-51341 Re: Suite name is not shown on the main page and method results page A side note: I would move "Failed Configurations" to the top (right after "total tests"), as it is likely to be more important than "skipped/failed" tests. "Failed configurations" might cause tests to be skipped not the other way around. Add Comment This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-51341) Suite name is not shown on the main page and method results page
Title: Message Title Vladimir Sitnikov updated an issue Jenkins / JENKINS-51341 Suite name is not shown on the main page and method results page Change By: Vladimir Sitnikov Attachment: failed_configs.png Add Comment This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-51341) Suite name is not shown on the main page and method results page
Title: Message Title Vladimir Sitnikov updated an issue Jenkins / JENKINS-51341 Suite name is not shown on the main page and method results page Change By: Vladimir Sitnikov Attachment: failed_configs.png Add Comment This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-51341) Suite name is not shown on the main page and method results page
Title: Message Title Vladimir Sitnikov updated an issue Jenkins / JENKINS-51341 Suite name is not shown on the main page and method results page Change By: Vladimir Sitnikov Comment: A side note: I would move "Failed Configurations" to the top (right after "total tests"), as it is likely to be more important than "skipped/failed" tests. "Failed configurations" might cause tests to be skipped not the other way around. !failed_configs.png|thumbnail! Add Comment This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-51341) Suite name is not shown on the main page and method results page
Title: Message Title Vladimir Sitnikov updated an issue Jenkins / JENKINS-51341 Suite name is not shown on the main page and method results page Change By: Vladimir Sitnikov Attachment: failed_configs.png Add Comment This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-51341) Suite name is not shown on the main page and method results page
Title: Message Title Vladimir Sitnikov commented on JENKINS-51341 Re: Suite name is not shown on the main page and method results page There are quite a few tests: And it turns out certain test is listed 3 times: , , and Note: those are different executions of the same test method (there are just multiple suite xml files that list the same method name with different suite parameters), so the result file is parsed properly. It is just representation that makes the whole thing hard to reason about. Add Comment This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-51341) Suite name is not shown on the main page and method results page
Title: Message Title Vladimir Sitnikov updated an issue Jenkins / JENKINS-51341 Suite name is not shown on the main page and method results page Change By: Vladimir Sitnikov Attachment: failed_configs.png Add Comment This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-51341) Suite name is not shown on the main page and method results page
Title: Message Title Vladimir Sitnikov updated an issue Jenkins / JENKINS-51341 Suite name is not shown on the main page and method results page Change By: Vladimir Sitnikov Attachment: 3of3.png Attachment: 2of3.png Attachment: 1of3.png Attachment: overall.png Add Comment This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit
[JIRA] (JENKINS-51341) Suite name is not shown on the main page and method results page
Title: Message Title Vladimir Sitnikov commented on JENKINS-51341 Re: Suite name is not shown on the main page and method results page A side note: I would move "Failed Configurations" to the top (right after "total tests"), as it is likely to be more important than "skipped/failed" tests. "Failed configurations" might cause tests to be skipped not the other way around. Add Comment This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
