Details

    • Improvement
    • Status: Reopened
    • Major
    • Resolution: Unresolved
    • None
    • None
    • None

    Description

      As outlined in https://issues.apache.org/jira/browse/INFRA-18748?focusedCommentId=16885091&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16885091 and discussed in https://lists.apache.org/thread.html/7ba9424ae1cadd61363a5c6e7d12dec9f5b424b1f68e27915032fbab@%3Cprivate.infra.apache.org%3E it is no longer allowed to automatically build PRs from non-committers on ASF infra.

      Therefore another solution needs to be found to be able to validate PRs from contributors. This validation should include at least a Maven build and the validation of SonarQube rules.

      Several options come to my mind

      1. Use CloudBees Code Ship https://app.codeship.com/home. Currently it is unclear whether there is a dedicated ASF account. I asked about it in https://issues.apache.org/jira/browse/INFRA-18973. Preferred option as probably the Jenkinsfile can be reused.
      2. Use Travis CI. There is a dedicated ASF account but it a) needs to be enabled by INFRA per project and b) requires to maintain another build script next to the Jenkinsfile we already have
      3. Use another 3rd party build provider

      This was also discussed during the Sling Hackathon 2019 (https://lists.apache.org/thread.html/fb675eda239779450943623490e5a232786464df1dfb1feac5ec4ee0@%3Cdev.sling.apache.org%3E).

      Attachments

        1. Screenshot 2022-01-02 at 20.46.48.png
          174 kB
          Konrad Windszus

        Issue Links

          Activity

            kwin Konrad Windszus added a comment - - edited

            I opened https://app.codeship.com/apache-sling for PoC purposes and I am now waiting for INFRA to approve the codeship app for Github (https://github.com/apps/codeship/installations/new). Asked in https://issues.apache.org/jira/browse/INFRA-18973.

            kwin Konrad Windszus added a comment - - edited I opened https://app.codeship.com/apache-sling for PoC purposes and I am now waiting for INFRA to approve the codeship app for Github ( https://github.com/apps/codeship/installations/new ). Asked in https://issues.apache.org/jira/browse/INFRA-18973 .
            kwin Konrad Windszus added a comment - - edited

            CodeShip is not an option as this requires admin rights for their GitHub app (https://documentation.codeship.com/general/about/permissions/#github). I think now Githubs Actions are worth to look into (https://help.github.com/en/actions). Similar to the approach for the Jenkinsfile we could try to only reference a single action from the repository specific workflow. That action should be located in a dedicated repo similar to https://github.com/apache/sling-tooling-jenkins and should contain the same steps (https://help.github.com/en/actions/automating-your-workflow-with-github-actions/configuring-a-workflow#referencing-actions-in-your-workflow). rombert WDYT?

            kwin Konrad Windszus added a comment - - edited CodeShip is not an option as this requires admin rights for their GitHub app ( https://documentation.codeship.com/general/about/permissions/#github ). I think now Githubs Actions are worth to look into ( https://help.github.com/en/actions ). Similar to the approach for the Jenkinsfile we could try to only reference a single action from the repository specific workflow. That action should be located in a dedicated repo similar to https://github.com/apache/sling-tooling-jenkins and should contain the same steps ( https://help.github.com/en/actions/automating-your-workflow-with-github-actions/configuring-a-workflow#referencing-actions-in-your-workflow ). rombert WDYT?

            kwin - yes, we could do that. The only limitation that I am aware of is that from Github actions will not be able to perform privileged actions, such as:

            • deploying SNAPSHOT artifacts on repository.apache.org
            • deploying the Sling site

            This means that we will be limited to building PRs only, so we'll have to keep Jenkins as well for the builds that are not PRs.

            rombert Robert Munteanu added a comment - kwin - yes, we could do that. The only limitation that I am aware of is that from Github actions will not be able to perform privileged actions, such as: deploying SNAPSHOT artifacts on repository.apache.org deploying the Sling site This means that we will be limited to building PRs only, so we'll have to keep Jenkins as well for the builds that are not PRs.

            Github actions currently don't support external definitions (https://github.community/t5/GitHub-Actions/External-workflow-configuration/td-p/33529). Adding the same workflow action to each and every repo is not feasible for Sling.

            kwin Konrad Windszus added a comment - Github actions currently don't support external definitions ( https://github.community/t5/GitHub-Actions/External-workflow-configuration/td-p/33529 ). Adding the same workflow action to each and every repo is not feasible for Sling.

            https://cwiki.apache.org/confluence/display/INFRA/.asf.yaml+features+for+git+repositories mentions a github_whitelist option in the .asf.yaml file, to "designate a GitHub person as a 'safe/reliable' person" for Jenkins builds, isn't that what we need here?

            bdelacretaz Bertrand Delacretaz added a comment - https://cwiki.apache.org/confluence/display/INFRA/.asf.yaml+features+for+git+repositories mentions a github_whitelist option in the .asf.yaml file, to "designate a GitHub person as a 'safe/reliable' person" for Jenkins builds, isn't that what we need here?

            I don’t think that approach scales as it involves committing to the master branch for each whitelisting. The idea is that we check PRs before a committer is involved.

            kwin Konrad Windszus added a comment - I don’t think that approach scales as it involves committing to the master branch for each whitelisting. The idea is that we check PRs before a committer is involved.

            With ASF migrating to Cloudbees (SLING-9594) this may be supported OOTB...

            kwin Konrad Windszus added a comment - With ASF migrating to Cloudbees ( SLING-9594 ) this may be supported OOTB...

            This still does not work on ASF Jenkins for non-committers. The only viable way from my perspective is to leverage GH Actions, but due to load issues (https://cwiki.apache.org/confluence/display/BUILDS/GitHub+Actions+status) and also the maintenance effort (in addition to Jenkins @ ASF) I would rather close this as won't fix. Feel free to reopen if you disagree.

            kwin Konrad Windszus added a comment - This still does not work on ASF Jenkins for non-committers. The only viable way from my perspective is to leverage GH Actions, but due to load issues ( https://cwiki.apache.org/confluence/display/BUILDS/GitHub+Actions+status ) and also the maintenance effort (in addition to Jenkins @ ASF) I would rather close this as won't fix. Feel free to reopen if you disagree.

            Reopening as I just figured out the GitHub Branch Source Plugin (https://plugins.jenkins.io/github-branch-source/) has a trust setting in more recent version. This is currently set to "Nobody". I noone objects, we could change the configuration for "Trust" in https://ci-builds.apache.org/job/Sling/job/modules/configure:

            kwin Konrad Windszus added a comment - Reopening as I just figured out the GitHub Branch Source Plugin ( https://plugins.jenkins.io/github-branch-source/ ) has a trust setting in more recent version. This is currently set to "Nobody". I noone objects, we could change the configuration for "Trust" in https://ci-builds.apache.org/job/Sling/job/modules/configure:

            People

              kwin Konrad Windszus
              kwin Konrad Windszus
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

                Created:
                Updated: