SCMCheckout in WorkflowRun

[Ullrich Hafner]

In the warnings plugin I am visualizing the authors of a warning by querying the associated SCM. This works quite well for Git if the Jenkinsfile checks out the source code into the top level folder. However, if the checkout is placed within a directory, the plugin cannot find the git repository anymore.

E.g., a Jenkinsfile

stages {\n"
+ "    stage('Prepare') {\n"
+ "      steps {\n"
+ "        dir('src') {\n"
+ "          checkout scm\n"
+ "        }\n"
+ "      }\n"
+ "    }\n"

Creates a git directory in the src folder. When I create a GitClient from the workspace it does not find the .git directory. 

It seems that the correct path to the subfolder is stored in instances of SCMCheckout, however these classes are not public.  

Is there a public API to obtain the actual subfolder of the Git repositories of a pipeline?

[Jesse Glick]

On Wed, Jul 10, 2019 at 4:07 PM Ullrich Hafner <ullrich...@gmail.com> wrote:
> Is there a public API to obtain the actual subfolder of the Git repositories of a pipeline?

Not as such. (You could work your way to more or less that information
by inspecting the flow graph.) Anyway how would that even work if the
checkout is done, say, in a Kubernetes pod which is then discarded?
You would have to implement `SCMListener.onCheckout` and do your
analysis the moment the checkout happens, while the remote filesystem
is still live.

The more supported path is to call `getChangeSets()` and proceed from
there, without touching the build’s own private checkout.

[Ullrich Hafner]

>> Is there a public API to obtain the actual subfolder of the Git repositories of a pipeline?

> Anyway how would that even work if the
> checkout is done, say, in a Kubernetes pod which is then discarded?
> You would have to implement `SCMListener.onCheckout` and do your
> analysis the moment the checkout happens, while the remote filesystem
> is still live.

Well, 99% of the use cases in my plugin are quite similar to the following pseudo code

1. Checkout from SCM
2a Build
2b Record warnings and blame authors in affected files
3. Discard node

So in 2b I still have access to the workspace and the SCM, or am I missing something? (If someone uses the recordIssues step after 3 it will not work.)
I cannot do the Git analysis before 2b because I do not yet know the files with warnings.

So is it ok to listen for SCMListener.onCheckout events and create actions in the run that store the Git workspace path? It seems to be a little bit overkill for my plugin, but it is feasible.

[Jesse Glick]

On Wed, Jul 10, 2019 at 5:14 PM Ullrich Hafner <ullrich...@gmail.com> wrote:
> 1. Checkout from SCM
> 2a Build
> 2b Record warnings and blame authors in affected files

Yet there is a `dir` step in there. So are you talking about this?

dir('src') {
checkout scm
sh 'mvn install'
parseWarnings()
}

In this case the contextual `FilePath` available to the
`parseWarnings` step will be in the subdirectory—so you do not need to
do anything special.

For that matter, even if someone writes

dir('sources') {
checkout scm
sh 'mvn install'
}
parseWarnings files: 'sources/src/main/java/**.java'

then the filenames you receive will be absolute, and if you want to
run `git blame` on something you can trivially find the repository
root simply by searching up the directory tree for a child directory
named `.git`.

Perhaps I am missing something about what you are really asking.

[Ullrich Hafner]

>
> On Wed, Jul 10, 2019 at 5:14 PM Ullrich Hafner <ullrich...@gmail.com> wrote:
>> 1. Checkout from SCM
>> 2a Build
>> 2b Record warnings and blame authors in affected files
>
> Yet there is a `dir` step in there. So are you talking about this?
>
> dir('src') {
> checkout scm
> sh 'mvn install'
> parseWarnings()
> }
>
> In this case the contextual `FilePath` available to the
> `parseWarnings` step will be in the subdirectory—so you do not need to
> do anything special.
>

Ah, thanks for noting that! This is exactly the use case I am trying to solve, sorry for the confusion.
I did not know that the FilePath context element is actually using the dir argument.

> For that matter, even if someone writes
>
> dir('sources') {
> checkout scm
> sh 'mvn install'
> }
> parseWarnings files: 'sources/src/main/java/**.java'
>
> then the filenames you receive will be absolute, and if you want to
> run `git blame` on something you can trivially find the repository
> root simply by searching up the directory tree for a child directory
> named `.git`.
>
> Perhaps I am missing something about what you are really asking.
>

> --
> 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/CANfRfr3qBhb%2BYcxLNtm-JP_T8rcVvikP-kVwYiknnFJv25jskQ%40mail.gmail.com.
> For more options, visit https://groups.google.com/d/optout.