opendevstack / ods-jenkins-shared-library

Shared Jenkins library which all ODS projects & components use - provisioning, SonarQube code scanning, Nexus publishing, OpenShift template based deployments and repository orchestration
Apache License 2.0
70 stars 57 forks source link

Checkout tags and commits (SHA1) on slave #102

Open ungerts opened 5 years ago

ungerts commented 5 years ago

Currently, on slave only branches below refs/heads/ can be checked out. https://github.com/opendevstack/ods-jenkins-shared-library/blob/aa765fc7789358d1470000202a6e26b1650c401d/src/org/ods/OdsPipeline.groovy#L192 Aim of this ticket is to discuss whether we need to enable checking out tags and commits (SHA). At least, we should provide all possibilities Openshift build config provides.

michaelsauter commented 5 years ago

Good point. Tentatively yes from my side :)

tjaeschke commented 5 years ago

From my side I also would say yes.

ungerts commented 5 years ago

The simplest solution would be to checkout the commit hash on the slave in any case. Git-Plugin doesn’t do anything else, even if a branch is specified. In this case, the commit is determined first. ODS context, however, knows the commit already.

Example checkout:

> git fetch --tags --progress https://github.com/ungerts/ods-provisioning-app.git +refs/heads/*:refs/remotes/origin/*
 > git rev-parse refs/remotes/origin/experimental/mro^{commit} # timeout=10
 > git rev-parse refs/remotes/origin/refs/heads/experimental/mro^{commit} # timeout=10
Checking out Revision fc878841f980e1843acd462b0927b7ef46f84a1f (refs/remotes/origin/experimental/mro)
 > git config core.sparsecheckout # timeout=10
 > git checkout -f fc878841f980e1843acd462b0927b7ef46f84a1f
clemensutschig commented 5 years ago

@ungerts - even with this fix gitBranch is still showing HEAD

clemensutschig commented 5 years ago

@ungerts branch = script.sh( returnStdout: true, script: "git name-rev ${branch} | cut -d ' ' -f2", label : 'resolving GIT branch to build').trim()

gets me in the mro case the remote/origin/master ... which is what we want, I assume ...

and using sed after .. we can get the real branch name ... you can find the branch with it on our internal *dev env

clemensutschig commented 4 years ago

@ungerts -> close?