Continuous deployment of the `main` branch

[LorenzoBettini]

As suggested here by @szarnekow #2620 (comment) we could deploy the "nightly" p2 site and the Maven snapshots when we push to the main branch.

I think we can do that by triggering the current nightly job from the main Jenkinsfile as a last stage.

[HannesWell]

Deploying a nightly for each push is a good suggestion.

I think we can do that by triggering the current nightly job from the main Jenkinsfile as a last stage.

That would be possible, but IMHO it would be simpler to just squash the two stages of the nightly-deploy Jenkins
https://github.com/eclipse/xtext/blob/d84f253401bf0470fbd389fb895b29894d74b912/jenkins/nightly-deploy/Jenkinsfile#L26-L46

... into one and add it as last stage of the 'main' Jenkins file, which is guarded with a when expression.
It would probably be just be

    stage('Maven Tycho Build, Sign, Deploy') {
      when {
        branch 'main'
      }
      steps {
        withCredentials([file(credentialsId: 'secret-subkeys.asc', variable: 'KEYRING')]) {
          sh 'gpg --batch --import "${KEYRING}"'
          sh 'for fpr in $(gpg --list-keys --with-colons | awk -F: \'/fpr:/ {print $10}\' | sort -u); do echo -e "5\ny\n" | gpg --batch --command-fd 0 --expert --edit-key ${fpr} trust; done'
        }
        sshagent(['projects-storage.eclipse.org-bot-ssh']) {
          sh '''
            echo ${REPOSITORY_PATH}
            ssh genie.xtext@projects-storage.eclipse.org "mkdir -p $REPOSITORY_PATH"
            ./full-deploy.sh -Peclipse-sign,sonatype-oss-release,release-snapshot
          '''
        }
      }
    }

plus a environment section for the REPOSITORY_PATH environment variable

  environment {
    DOWNLOAD_AREA = '/home/data/httpd/download.eclipse.org/modeling/tmf/xtext'
    REPOSITORY_PATH="${DOWNLOAD_AREA}/updates/nightly"
  }

But this could also be inlined into the scripts. Scripts are printed on the Jenkins console by default. Or probably even better, the mojos called in the pom should be enhanced to create a missing parent directories, so that this step is not necessary at all.

With this approach the nightly-deploy/Jenkinsfile can be removed and additional maintenance can be saved.
Since the deploy-build is already defined in a script, why not use them? :)

[LorenzoBettini]

@HannesWell sorry I forgot to answer.

That's already been implemented in the PR.

I prefer to trigger the other job, this way, the other job can also be run manually to deploy a snapshot manually. Putting everything in a single Jenkinsfile would make this hard (e.g., wait for the tests to complete). Moreover, as you might have understood by now, I prefer keeping things separate in small files, than having a single bigger file ;)

As I also said in the original comment, we cannot sign when we run tests because Java would complain about different classes of the same package with different signatures.

Finally, as you can see from the PR, since the main Jenkinsfile is also triggered nightly, the when condition for triggering the deployment is slightly more complex than just checking the branch.