Is it possible to configure job at https://jenkins.ci.cloudbees.com/job/plugins/ to use java 8?

[Patrick Huang]

Hi, 

Our plugin declare java 8 in pom and uses java 8 in source. But the auto 
created job at https://jenkins.ci.cloudbees.com/job/plugins/ is 
running/using java 7:

Java version: 1.7.0_79, vendor: Oracle Corporation
Java home: /opt/java/sdk/Oracle/x86_64/jdk1.7.0_79/jre


So it failed the build. Is there anyway we can configure the job to use 
java 8? Like putting some magic word in github PR description? Should I be 
better off applying a job at https://ci.jenkins.io/job/Plugins/? Thanks.

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/bfb1eb49-4aa3-4eb3-9673-ad6976143fb4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Translation management plugin

[Patrick Huang]

Hi, take a look at http://zanata.org/ (Opensource translation management 
platform used by Fedora, Openstack community and Red Hat internally)

We are developing a Jenkins plugin 
https://github.com/jenkinsci/zanata-plugin right now (Please wait until 
pull request 3 is merged or just use that branch to build it locally). It 
can integrate with a Zanata server and SCM. Not yet released but it's 
getting there. Hope this helps.

On Monday, February 20, 2017 at 1:02:01 AM UTC+10, Marek Be wrote:
>
> I am thinking of creating a new Jenkins plugin that will make application 
> localization easier for people of developer and business roles in the 
> project. The goal I want to achieve is create a single page where all 
> translations from the message bundle files found in the codebase are 
> displayed as editable entities in a convenient way. Any updates could be 
> previewed instantly in some preconfigured, dedicated server instance. The 
> plugin would be integrated with popular SCM tools.
> Do you know if anything similar already exists?
> Do you think Jenkins plugin API will allow me to achieve aforementioned 
> functionalities?
>
> Thanks!
>

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/5cba74f6-be69-470b-ad17-59912d3f60d4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Jenkins developers who are also IntelliJ users, please all pile on this bug

[Kanstantsin Shautsou]

Intellij users let's make jenkins integration! I'm more confused with IDEA 
APIs, than cloud apis.

2016.3 fails too much so i'm using 2016.2 and have no issues ;)

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/f2c91f73-7cf8-4a89-8491-5541e8905a8d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: disk-usage-plugin seems to be abandoned

[Kanstantsin Shautsou]

Confirm. @lvotypko made refactorings and disappeared. 
I made few attempts to request release with fixes in last half year, but 
nobody from RedHat made release. Plugin is very useful and before lvotypko 
i was even ready to refactor or write new. 
Who remember @ogondza email? Please CC him. 

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/75c14ccf-3f37-405b-ba06-b43c3a739d21%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Project ideas for student projects in the area of testing

[Mark Waite]

I'm think that a Jenkins job which asserts the conditions related to a bug
report is a regression test.  I admit that the Jenkins jobs I create are
not Selenium tests, and they do not require a web browser in order to run.
They are definitely not able to exercise JavaScript, and they do not
evaluate behavior across multiple browsers.  If the goal is to check
JavaScript or to check browser compatibility, then Jenkins jobs are a poor
choice.

If the goal is to duplicate a bug report, and reuse the steps that
duplicated the bug report for later regression testing, then I think a
Jenkins job is simpler to create, easier to maintain, and easier to
diagnose than a Selenium test.

Ulrich, if you are interested in some "test drive" bug reports from the git
plugin or the git client plugin, you can review how I use the technique to
report and duplicate bugs in:

   - JENKINS-42204  -
   NPE due to recent GitSCMSource change
   - JENKINS-41948  -
   NoSuchMethodError scanning multi-branch project
   - JENKINS-41867  -
   IllegalStateException scanning multi-branch project
   - JENKINS-41785  -
   Pipeline status icon no longer shows worst status

If your students would like to try to duplicate bugs that I think are
interesting, I would suggest starting with:

   - JENKINS-38860  -
   renamed submodules fail checkout
   - JENKINS-41553  -
   submodule defs read from wrong location
   - JENKINS-42004  -
   jobs triggered unnecessarily (scenario 1)
   - JENKINS-41906  -
   jobs triggered unnecessarily (scenario 2)
   - JENKINS-40733  -
   notifyCommit provides wrong parameters
   - JENKINS-40352  -
   duplicate changesets in pipeline jobs (and other jobs)
   - JENKINS-39621  -
   infinite loop of job rebuilds

Those bug reports are likely well suited to creating one or more jobs to
show that the bug exists.  If they want to use the infrastructure already
provided in the lts-with-plugins branch
 of my docker
repository , they're welcome to do
that.

If you decide that the technique works well enough for the students, then
you can consider attempting other bugs from the git-plugin and
git-client-plugin projects, most recent bugs first.  I suspect other SCM
system bugs (Subversion, etc.) are reasonably well suited to the same
technique.

I've also found that it is quite powerful to create a pipeline based branch
per bug verification job so that Jenkins will automatically create the job
and execute it.  You can see examples of that technique in my jenkins-bugs
repository  (which is
referenced in several different ways from the docker instance).  That has
the benefit that I don't have to commit anything to the docker repository,
and the Jenkins pipeline code still creates and runs a job per bug.

I'm also OK if you decide it is better to submit pull requests to the
acceptance test harness.  The acceptance test harness has the compelling
benefit that there are many more people creating Selenium tests with the
acceptance test harness, and there are many more locations where those
tests can be executed.

In my case, I don't need the flexibility of a Selenium test, and I want the
easier diagnose and trivial parallel execution that comes from running a
Jenkins instance with multiple slaves and with tests defined as Jenkins
jobs.

Thanks!
Mark Waite

P.S. I have pipeline utility functions assertLogContains and
assertLogDoesNotContain to search for specific strings in the log files.
When one of those functions finds something unexpected, it marks the job as
"Unstable".  I can then search for all failed jobs and all unstable jobs in
my Jenkins instance to locate test failures.  Because it is a docker
instance, I can spread the execution load trivially across multiple agents
by adding or deleting agents.  I get interesting (and useful) test
randomization by choosing a mix of operating systems (Windows, CentOS 6.
CentOS 7, Debian 7, Debian 8, Ubuntu 14, Ubuntu 16, etc.) and git versions.



On Fri, Feb 17, 2017 at 5:47 AM Jesse Glick  wrote:

> I would also much rather see a genuine regression test. If some aspect of
> ATH is too weak to reproduce the bug properly, then that is what needs
> fixing.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> 

disk-usage-plugin seems to be abandoned

['FredG' via Jenkins Developers]

Hi,

It seems like the disk-usage-plugin 
 has been 
abandoned.
Last commit is from Feb 10, 2016, last release was done October 1, 2015.
The current maintainer lvotypko  did not react 
to messages and mentions on pull request #34 
.

Since there are quite a few commits with fixes that people are waiting for, 
including an annoying UI bug (see PR #34) that causes Icons not to show up,
I'd like to propose the following:

   - let's wait for one week
   - if maintainer does not reply or react somehow, let someone else 
   release the plugin (any volunteers?)
   - try to contact the maintainer again, if that fails, mark the plugin 
   for adoption
   

Please let me know, if this should be handled somehow differently.


Regards,


Fred

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/8ebc74f4-c623-4358-a1b7-760a5e0fc165%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

ATH under Windows

[Ullrich Hafner]

Is someone running the acceptance test harness under Windows? The last time I 
tried it did not work, but this was several months ago.  

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/B8AA6290-5E6F-4B3E-9AB9-590F5829CE3D%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: plugin data migration - potential incompatibility

[Robert St. John]

I would prefer to do a 1:N transformation, so ItemListener.onLoad() it is, 
then.  I'll make it do as little as possible.  Thanks, all, for your time 
and advice.

On Monday, February 20, 2017 at 7:47:44 AM UTC-7, Stephen Connolly wrote:
>
>
>
> On 20 February 2017 at 14:11, Robert St. John  > wrote:
>
>> The only problem I see with the readResolve() solution is the possible 
>> conversion of one build step to many.  Unless returning a list of 
>> SimpleBuildStep objects from readResolve() would magically work,
>>
>
> Are you planning on doing a 1:N transformation then?
>
> If it is 1:1 then readResolve is perfect
>
> If it is 1:N then onLoad listener as the prebuild will prevent correct 
> analysis of the build up front by some tools
>  
>
>> that approach could potentially banish some persisted configuration to 
>> the Phantom Zone.  While I mentioned earlier that actual users are 
>> relatively few, and the problematic scenario unlikely, I have no way of 
>> knowing for sure, and I'd still prefer not to silently vaporize anyone's 
>> configuration.
>>
>> To be honest, I'm starting to favor my original solution of migrating the 
>> data in the prebuild() method, as that would have minimal performance 
>> impact compared to ItemLIstener.onLoad(), and as far as I can tell, that 
>> would guarantee the step never runs before upgrading itself and its parent 
>> Project.
>>
>> As another alternative, what about an @Initializer(before = 
>> InitMilestone.COMPLETED, after = InitMilestone.JOB_LOADED)?
>>
>> Continued thanks for all your inputs.
>>
>> Robert
>>
>>
>> On Saturday, February 18, 2017 at 3:01:14 AM UTC-7, Stephen Connolly 
>> wrote:
>>>
>>> You can strip out the *functionality* from the old class and add a 
>>> readResolve method to the old class. The readResolve will convert itself 
>>> into an equivalent instance of the new class... no messing with onLoad... 
>>> much less performance impact
>>>
>>> It is the way I recommend.
>>> On Fri 17 Feb 2017 at 20:55, Robert St. John  wrote:
>>>
 What would be the advantage of renaming the builder class?

 On Friday, February 17, 2017 at 1:41:41 PM UTC-7, Daniel Beck wrote:

>
> > On 17.02.2017, at 21:38, Jesse Glick  wrote: 
> > 
> > In that case maybe just rename the `Builder` class rather than even 
> > wasting time on migration. 
>
> + 
> https://wiki.jenkins-ci.org/display/JENKINS/Marking+a+new+plugin+version+as+incompatible+with+older+versions
>  
>
> -- 
 You received this message because you are subscribed to the Google 
 Groups "Jenkins Developers" group.
 To unsubscribe from this group and stop receiving emails from it, send 
 an email to jenkinsci-de...@googlegroups.com.
 To view this discussion on the web visit 
 https://groups.google.com/d/msgid/jenkinsci-dev/a96b4a59-9549-4f31-a7b8-9bc1bf817fb0%40googlegroups.com
  
 
 .
 For more options, visit https://groups.google.com/d/optout.

>>> -- 
>>> Sent from my phone
>>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Jenkins Developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to jenkinsci-de...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/jenkinsci-dev/0a70bcd0-a47b-4f03-881a-ae77525e8be2%40googlegroups.com
>>  
>> 
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/5f4fa0df-1350-4615-a9e1-646d762e92be%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Build details of pipeline job via API

[Graham Lyons]

Hi,

I'm trying to get information about running builds on Jenkins agents, with 
and without pipelines. 'Old-style' jobs show up just fine but pipelines 
only ever appear as placeholder tasks:

{
   "currentExecutable": {
 "_class": 
"org.jenkinsci.plugins.workflow.support.steps.ExecutorStepExecution$PlaceholderTask$PlaceholderExecutable"
   },
   "currentWorkUnit": {

},
   "idle": false,
   "likelyStuck": false,
   "number": 1,
   "progress": 84
 }

I'm using Jenkins ver. 2.19.1 but, looking at the source code, I don't see 
any changes relating to this in later versions. I could be wrong about that 
of course.

Is this expected? Is there a way to make it behave differently? How does 
the /ajaxExecutors endpoint get its data?

If anyone can help then I'd really appreciate it.

Thanks,
Graham

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/fd71962c-56f2-48ac-92d3-fca5032171c7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Using milestone within a parallel task

[Daniel Beland]

Hi,



There's a restriction currently that prevents the use of a milestone step 
within a parallel execution of multiple tasks and I'm trying to understand 
if this is something that we could remove (I would submit a PR), but I'd 
like to discuss it first.


I have multiple jobs with the following pattern:

1. Build and run unit tests 
2. In parallel: 
  a. Run Integration Tests
  b. Generate Documentation
  c. Run very slow unit tests (if any)

I need to limit the number of jobs running integration tests to 1 per 
server and I want to use the milestone step to cancel previous builds when 
a newer job acquires the lock.
Currently my only option is to acquire the lock and set the milestone right 
before the parallel task, but then I will keep the lock until all branches 
complete and prevent other jobs from running their integration tests.
My only other option would be to take the integration tests branch out of 
the parallel step and run it before or after, but then my job will take 
longer to build.

Ideally, I'd like to keep the same structure but only lock resources and 
use the milestone step within the integration tests branch.


Option A: Modify the milestone plugin to allow it within a parallel 
execution, (no restriction at all)?

  - I understand it becomes unpredictable if used incorrectly , but we 
could print a WARNING in the console and let the users make sure they use 
it correctly (milestone number sequence need to increase, whatever the 
order they are executed, etc).


Option B: Allow a single milestone step for all branches of a parallel step?

  - Then the milestone step order becomes predictable, but it could mean 
stopping other branches that are currently executing


Option C: We cannot modify the current behavior

  - Please let me know why this is a bad idea to allow it in a branch



Please let me know what you think.
It would really improve my build times if I can lock only the integration 
tests branch.


Thanks,
Daniel






-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/b6360b88-273f-4e0b-9a46-a613ecd1287e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: plugin data migration - potential incompatibility

[Stephen Connolly]

On 20 February 2017 at 14:11, Robert St. John  wrote:

> The only problem I see with the readResolve() solution is the possible
> conversion of one build step to many.  Unless returning a list of
> SimpleBuildStep objects from readResolve() would magically work,
>

Are you planning on doing a 1:N transformation then?

If it is 1:1 then readResolve is perfect

If it is 1:N then onLoad listener as the prebuild will prevent correct
analysis of the build up front by some tools


> that approach could potentially banish some persisted configuration to the
> Phantom Zone.  While I mentioned earlier that actual users are relatively
> few, and the problematic scenario unlikely, I have no way of knowing for
> sure, and I'd still prefer not to silently vaporize anyone's configuration.
>
> To be honest, I'm starting to favor my original solution of migrating the
> data in the prebuild() method, as that would have minimal performance
> impact compared to ItemLIstener.onLoad(), and as far as I can tell, that
> would guarantee the step never runs before upgrading itself and its parent
> Project.
>
> As another alternative, what about an @Initializer(before =
> InitMilestone.COMPLETED, after = InitMilestone.JOB_LOADED)?
>
> Continued thanks for all your inputs.
>
> Robert
>
>
> On Saturday, February 18, 2017 at 3:01:14 AM UTC-7, Stephen Connolly wrote:
>>
>> You can strip out the *functionality* from the old class and add a
>> readResolve method to the old class. The readResolve will convert itself
>> into an equivalent instance of the new class... no messing with onLoad...
>> much less performance impact
>>
>> It is the way I recommend.
>> On Fri 17 Feb 2017 at 20:55, Robert St. John  wrote:
>>
>>> What would be the advantage of renaming the builder class?
>>>
>>> On Friday, February 17, 2017 at 1:41:41 PM UTC-7, Daniel Beck wrote:
>>>

 > On 17.02.2017, at 21:38, Jesse Glick  wrote:
 >
 > In that case maybe just rename the `Builder` class rather than even
 > wasting time on migration.

 + https://wiki.jenkins-ci.org/display/JENKINS/Marking+a+new+pl
 ugin+version+as+incompatible+with+older+versions

 --
>>> You received this message because you are subscribed to the Google
>>> Groups "Jenkins Developers" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to jenkinsci-de...@googlegroups.com.
>>> To view this discussion on the web visit https://groups.google.com/d/ms
>>> gid/jenkinsci-dev/a96b4a59-9549-4f31-a7b8-9bc1bf817fb0%40goo
>>> glegroups.com
>>> 
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>> --
>> Sent from my phone
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/jenkinsci-dev/0a70bcd0-a47b-4f03-881a-ae77525e8be2%
> 40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CA%2BnPnMxzjYYN0yx1%2Bgkk%2BhPi8CU%3DiYSGmJW5014qG%3Dm3r9XJaQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: plugin data migration - potential incompatibility

[Robert St. John]

The only problem I see with the readResolve() solution is the possible 
conversion of one build step to many.  Unless returning a list of 
SimpleBuildStep objects from readResolve() would magically work, that 
approach could potentially banish some persisted configuration to the 
Phantom Zone.  While I mentioned earlier that actual users are relatively 
few, and the problematic scenario unlikely, I have no way of knowing for 
sure, and I'd still prefer not to silently vaporize anyone's configuration.

To be honest, I'm starting to favor my original solution of migrating the 
data in the prebuild() method, as that would have minimal performance 
impact compared to ItemLIstener.onLoad(), and as far as I can tell, that 
would guarantee the step never runs before upgrading itself and its parent 
Project.

As another alternative, what about an @Initializer(before = 
InitMilestone.COMPLETED, after = InitMilestone.JOB_LOADED)?

Continued thanks for all your inputs.

Robert


On Saturday, February 18, 2017 at 3:01:14 AM UTC-7, Stephen Connolly wrote:
>
> You can strip out the *functionality* from the old class and add a 
> readResolve method to the old class. The readResolve will convert itself 
> into an equivalent instance of the new class... no messing with onLoad... 
> much less performance impact
>
> It is the way I recommend.
> On Fri 17 Feb 2017 at 20:55, Robert St. John  > wrote:
>
>> What would be the advantage of renaming the builder class?
>>
>> On Friday, February 17, 2017 at 1:41:41 PM UTC-7, Daniel Beck wrote:
>>
>>>
>>> > On 17.02.2017, at 21:38, Jesse Glick  wrote: 
>>> > 
>>> > In that case maybe just rename the `Builder` class rather than even 
>>> > wasting time on migration. 
>>>
>>> + 
>>> https://wiki.jenkins-ci.org/display/JENKINS/Marking+a+new+plugin+version+as+incompatible+with+older+versions
>>>  
>>>
>>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Jenkins Developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to jenkinsci-de...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/jenkinsci-dev/a96b4a59-9549-4f31-a7b8-9bc1bf817fb0%40googlegroups.com
>>  
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
> -- 
> Sent from my phone
>

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/0a70bcd0-a47b-4f03-881a-ae77525e8be2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Changelog is now YAML and lives in the site repository

[Arnaud Héritier]

Ok. If main contributors are happy with it, I have nothing to say.

Le lun. 20 févr. 2017 à 12:42, Daniel Beck  a écrit :

>
> > On 20.02.2017, at 11:37, Arnaud Héritier  wrote:
> >
> > I don't like to have the changelog leaving outside of the project
> repository.
>
> It already was in the case of LTS (which AFAIK is the line more successful
> with users since we made it more discoverable on the site), and nobody
> cared. (And don't get me started on the uselessness of old LTS changelogs…)
>
> The technical 'changelog' is the (history in the) GitHub repository. What
> we're discussing here is user documentation, similar to the LTS upgrade
> guide. So it's not wrong for it to be in the site repository, where the
> rest of the documentation delivered via the site lives.
>
> > Am I the only one? Aren't we taking a risk to have it outdated?
>
> No less than before. At least for the past year, Oleg and I were the only
> ones filling in the changelog for releases (often on the Monday following
> the weekly release, so there were plenty of opportunities for others to
> contribute).
>
> In fact, we started actively discouraging changelog additions in PRs due
> to additional merge effort when they aren't merged the same week, and
> conflicts even when they are.
>
> Oleg and I wrote ~95% of the weekly changelog for the last year. Oliver
> and I wrote all of the LTS changelog. We were all in favor of this change
> as you can see in the PR referenced below.
>
> > Wasn't it possible to copy it from the project repo to the website build
> ?
>
> As I explained in
> https://github.com/jenkins-infra/jenkins.io/pull/661#issuecomment-280625408
> that would not be a great idea unless we add significant infra support
> around the changelog (generate its HTML independently from the site build).
> Doesn't seem worth the effort.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/257C76FC-E970-43FE-8096-72A44F9E68EA%40beckweb.net
> .
> For more options, visit https://groups.google.com/d/optout.
>
-- 
-
Arnaud Héritier
http://aheritier.net
Mail/GTalk: aheritier AT gmail DOT com
Twitter/Skype : aheritier

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CAFNCU--pwi%2BxvdLofkE%3DwnVvM82fYdKenmmxZwB99RZxQ7108Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Jelly/Plugin pipeline script support for optionalBlock

[Daniel Beck]

> On 20.02.2017, at 12:31, Robert Sandell  wrote:
> 
> https://wiki.jenkins-ci.org/display/JENKINS/Marking+a+new+plugin+version+as+incompatible+with+older+versions

… which should be only used when there's really no way to make work.

https://jenkins.io/project/governance/#compatibility-matters

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/7E3F0329-35F3-4CAC-8183-17B3D5467690%40beckweb.net.
For more options, visit https://groups.google.com/d/optout.

Re: Changelog is now YAML and lives in the site repository

[Daniel Beck]

> On 20.02.2017, at 11:37, Arnaud Héritier  wrote:
> 
> I don't like to have the changelog leaving outside of the project repository.

It already was in the case of LTS (which AFAIK is the line more successful with 
users since we made it more discoverable on the site), and nobody cared. (And 
don't get me started on the uselessness of old LTS changelogs…)

The technical 'changelog' is the (history in the) GitHub repository. What we're 
discussing here is user documentation, similar to the LTS upgrade guide. So 
it's not wrong for it to be in the site repository, where the rest of the 
documentation delivered via the site lives.

> Am I the only one? Aren't we taking a risk to have it outdated?

No less than before. At least for the past year, Oleg and I were the only ones 
filling in the changelog for releases (often on the Monday following the weekly 
release, so there were plenty of opportunities for others to contribute).

In fact, we started actively discouraging changelog additions in PRs due to 
additional merge effort when they aren't merged the same week, and conflicts 
even when they are.

Oleg and I wrote ~95% of the weekly changelog for the last year. Oliver and I 
wrote all of the LTS changelog. We were all in favor of this change as you can 
see in the PR referenced below.

> Wasn't it possible to copy it from the project repo to the website build ?

As I explained in 
https://github.com/jenkins-infra/jenkins.io/pull/661#issuecomment-280625408 
that would not be a great idea unless we add significant infra support around 
the changelog (generate its HTML independently from the site build). Doesn't 
seem worth the effort.

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/257C76FC-E970-43FE-8096-72A44F9E68EA%40beckweb.net.
For more options, visit https://groups.google.com/d/optout.

Re: Jelly/Plugin pipeline script support for optionalBlock

[Robert Sandell]

https://wiki.jenkins-ci.org/display/JENKINS/Hint+on+retaining+backward+compatibility

https://wiki.jenkins-ci.org/display/JENKINS/Marking+a+new+plugin+version+as+incompatible+with+older+versions

/B

On Sat, Feb 18, 2017 at 5:53 AM,  wrote:

>
> I've finally got it working, one remaining issue:
>
> Is there any way to make optionalProperty backwards compatible with
> optionalBlock?  When I publish the update to this plugin I don't want
> people to have to reconfigure there jobs.  If not, is there any way to mark
> the plugin as not backwards compatible?
>
>
> For anyone else struggling with this the answer is that an
> optionalProperty needs to have it's own class and config.jelly.
>
> For me that meant:
> 1. the original optional block became 
> 2. a new class:
>
> public class WaitTillCompleted extends 
> AbstractDescribableImpl
> {
>  private final boolean printLogOnFailure;
>  public boolean isPrintLogOnFailure() {
>   return printLogOnFailure;
>  }
>  @DataBoundConstructor
>  public WaitTillCompleted(boolean printLogOnFailure) {
> this.printLogOnFailure = printLogOnFailure;
> }
>
> @Extension
> public static class DescriptorImpl extends
> Descriptor {
> @Override
> public String getDisplayName() {
> return "";
> }
> }
> }
>
> 3. A new config.jelly for the above class
>
> 
>  xmlns:d="jelly:define" xmlns:l="/lib/layout" xmlns:t="/lib/hudson"
> xmlns:f="/lib/form">
>  field="printLogOnFailure" >
>   
> 
> 
>
> Cheers
>   Andrew
>
> On Friday, February 17, 2017 at 6:17:25 AM UTC+13, Jesse Glick wrote:
>
>> On Thu, Feb 16, 2017 at 4:30 AM,  wrote:
>> >The only example I can find this the ui-samples-plugin which has an
>> overly complicated example that I cannot follow.
>>
>> That is the cleanest example I know of. You can use GitHub search to
>> look for others but I cannot say whether they will be good examples or
>> bad examples, unless I wrote them myself.
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/jenkinsci-dev/86581742-e4dd-4e26-943b-62ba8bd4b7dc%
> 40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Robert Sandell
*Software Engineer*
*CloudBees Inc.*

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CALzHZS3Us-JvRqxm59R%2B8WeKqRNL79K9AugSzDkgBAWRKOEiLQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Changelog is now YAML and lives in the site repository

[Arnaud Héritier]

Even if I understand the technical need, I don't like to have the changelog
leaving outside of the project repository.
Am I the only one? Aren't we taking a risk to have it outdated?

Wasn't it possible to copy it from the project repo to the website build ?

On Mon, Feb 20, 2017 at 10:41 AM, Daniel Beck  wrote:

> Hi everyone,
>
> I moved the changelog to the site:
> https://github.com/jenkins-infra/jenkins.io/blob/master/
> content/_data/changelogs/weekly.yml
>
> All that's left in jenkinsci/jenkins is a tombstone file directing people
> to the file above:
> https://github.com/jenkinsci/jenkins/blob/master/changelog.html
>
> Daniel
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/jenkinsci-dev/9FA10634-1DE9-4E4E-BA7F-D8EC62F00CE5%40beckweb.net.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
-
Arnaud Héritier
http://aheritier.net
Mail/GTalk: aheritier AT gmail DOT com
Twitter/Skype : aheritier

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CAFNCU-_mmyHJ0%3DFd0hjmVZt-n-3W3KeJErbqQuwDa_CoLvMdxg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Jenkins developers who are also IntelliJ users, please all pile on this bug

[Stephen Connolly]

https://youtrack.jetbrains.com/issue/IDEA-168464

Because you have got to be having this issue too!

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CA%2BnPnMy%2B14%2BPNbrHyMxw6%2Bp-yJ5Qw4%3DYVQeioX53Z_8BTzdaQQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Changelog is now YAML and lives in the site repository

[Daniel Beck]

Hi everyone,

I moved the changelog to the site:
https://github.com/jenkins-infra/jenkins.io/blob/master/content/_data/changelogs/weekly.yml

All that's left in jenkinsci/jenkins is a tombstone file directing people to 
the file above:
https://github.com/jenkinsci/jenkins/blob/master/changelog.html

Daniel

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/9FA10634-1DE9-4E4E-BA7F-D8EC62F00CE5%40beckweb.net.
For more options, visit https://groups.google.com/d/optout.