Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-68547

Migrate logstash plugin documentation from Wiki to GitHub

    • Icon: Task Task
    • Resolution: Unresolved
    • Icon: Minor Minor
    • logstash-plugin
    • None

      Is there ongoing task for migrating wiki to github?

      I was trying to fix wiki about elasticsearch(related to JENKINS-67546), but I found that fixing wiki by contribution is not possible unless wiki is migrated.

      Would it be okay if I change a wiki a bit to make migration, and request a PR for it?

          [JENKINS-68547] Migrate logstash plugin documentation from Wiki to GitHub

          Mark Waite added a comment - - edited

          jinwookh thanks for your attention to this issue. Much appreciated.

          It can be added to INFRA-2328, but all infra issues are now tracked at https://github.com/jenkins-infra/helpdesk . Adding to to INFRA-2328 won't help others realize that a change is needed to redirect the wiki page to the matching page on plugins.jenkins.io

          Once a new release of the logstash plugin has been delivered, then this issue can be closed. Users will find the new documentation on plugins.jenkins.io within 24-48 hours of the new release of the logstash plugin. We can update the wiki redirects on the wiki.jenkins.io site later with a batch process.

          Mark Waite added a comment - - edited jinwookh thanks for your attention to this issue. Much appreciated. It can be added to INFRA-2328, but all infra issues are now tracked at https://github.com/jenkins-infra/helpdesk . Adding to to INFRA-2328 won't help others realize that a change is needed to redirect the wiki page to the matching page on plugins.jenkins.io Once a new release of the logstash plugin has been delivered, then this issue can be closed. Users will find the new documentation on plugins.jenkins.io within 24-48 hours of the new release of the logstash plugin. We can update the wiki redirects on the wiki.jenkins.io site later with a batch process.

          jinwookh han added a comment -

          markewaite  Thanks for the reply.
          Then there is no step that I need to further proceed, right?
          I am asking this because plugin migration guide says that creating new issue is required.
          https://www.jenkins.io/doc/developer/publishing/wiki-page/#migrating-from-wiki-to-github

          jinwookh han added a comment - markewaite   Thanks for the reply. Then there is no step that I need to further proceed, right? I am asking this because plugin migration guide says that creating new issue is required. https://www.jenkins.io/doc/developer/publishing/wiki-page/#migrating-from-wiki-to-github

          Mark Waite added a comment -

          The most important step is yet to be performed. The plugin needs to be released with the updated pom.xml .

          Opening a ticket at https://github.com/jenkins-infra/helpdesk is fine, once the plugin has released with the change.

          Mark Waite added a comment - The most important step is yet to be performed. The plugin needs to be released with the updated pom.xml . Opening a ticket at https://github.com/jenkins-infra/helpdesk is fine, once the plugin has released with the change.

          jinwookh han added a comment -

          Got it. Thanks for the guide.

          jinwookh han added a comment - Got it. Thanks for the guide.

          I thought the releases should happen automatically now since I added that .github/workflows/cd.yaml file
          But I don't think it worked... any help finding out whats wrong?

          Jakub Bochenski added a comment - I thought the releases should happen automatically now since I added that .github/workflows/cd.yaml file But I don't think it worked... any help finding out whats wrong?

          Mark Waite added a comment - - edited

          Automatic releases require that the master branch on ci.jenkins.io must pass automated tests.

          Merge pull request 113 to fix the failing test on the master branch and the plugin release should be generated automatically.

          Thanks for maintaining the plugin jbochenski!

          In case it helps, someone once showed me the location on github.com where the status of the master branch CI job is reported. Here's a screenshot:

          Mark Waite added a comment - - edited Automatic releases require that the master branch on ci.jenkins.io must pass automated tests. Merge pull request 113 to fix the failing test on the master branch and the plugin release should be generated automatically. Thanks for maintaining the plugin jbochenski ! In case it helps, someone once showed me the location on github.com where the status of the master branch CI job is reported. Here's a screenshot:

          jinwookh han added a comment -

          Failing CI has been solved, but still documentation in plugins.jenkins.io is outdated.
          It seems new plugin release is not generated automatically, so the documentation is not synced with github wiki.

          markewaite Could you figure out why the new release is not generated?
          The release page shows that latest release was done 10 months ago.(https://github.com/jenkinsci/logstash-plugin/releases)

           

          jinwookh han added a comment - Failing CI has been solved, but still documentation in plugins.jenkins.io is outdated. It seems new plugin release is not generated automatically, so the documentation is not synced with github wiki. markewaite Could you figure out why the new release is not generated? The release page shows that latest release was done 10 months ago.( https://github.com/jenkinsci/logstash-plugin/releases)  

          Mark Waite added a comment -

          I suspect that the continuous delivery process is detecting that none of the pull requests merged since the last releases have a label that indicates they are interesting enough to justify a release. When I look at the list of merged pull requests, they appear to be mostly dependency updates and they have no label.

          If you label one of the recent pull requests as an enhancement, that should be enough to trigger the release.

          Mark Waite added a comment - I suspect that the continuous delivery process is detecting that none of the pull requests merged since the last releases have a label that indicates they are interesting enough to justify a release. When I look at the list of merged pull requests, they appear to be mostly dependency updates and they have no label. If you label one of the recent pull requests as an enhancement, that should be enough to trigger the release.

          I thought the release is triggered, unless a commit is specially marked as uninteresting. How do I mark one as an enhancement?

          Jakub Bochenski added a comment - I thought the release is triggered, unless a commit is specially marked as uninteresting. How do I mark one as an enhancement?

          Mark Waite added a comment -

          Apply a label to one or more of the pull requests. In the platformlabeler and schedule build plugins, it would be "feature".

          You can check that from the "Actions" tab on GitHub. Here is a screenshot of the actions tab for a plugin that I maintain:

          You should probably modify the version numbering in the pom.xml file before the next release. Do a detailed review of the instructions at https://www.jenkins.io/doc/developer/publishing/releasing-cd/ especially the part about manually controlled prefix. Currently the plugin seems to use a 3 part version number as the manually controlled prefix then it appends the generated number. Usually you want at most one or two components to be manually controlled.

          Mark Waite added a comment - Apply a label to one or more of the pull requests. In the platformlabeler and schedule build plugins, it would be "feature". You can check that from the "Actions" tab on GitHub. Here is a screenshot of the actions tab for a plugin that I maintain: You should probably modify the version numbering in the pom.xml file before the next release. Do a detailed review of the instructions at https://www.jenkins.io/doc/developer/publishing/releasing-cd/ especially the part about manually controlled prefix. Currently the plugin seems to use a 3 part version number as the manually controlled prefix then it appends the generated number. Usually you want at most one or two components to be manually controlled.

            jbochenski Jakub Bochenski
            jinwookh jinwookh han
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated: