I think something along the lines of https://github.com/jenkinsci/workflow-multibranch-plugin/blob/workflow-multibranch-2.26/src/main/java/org/jenkinsci/plugins/workflow/multibranch/SCMBinder.java#L86-L143 should help.

I think I can try to get this done.

I've opened https://github.com/jenkinsci/inline-pipeline-plugin/pull/6

Turns out the problem I was chasing after wasn't because of that - it's because bitbucket-branch-source plugin using this `FirstCheckoutCompletedInvisibleAction` thing and my pipeline was doing `checkout` step to get some tooling before doing `checkout scm` step. So I will be back to the drawing board, but since I already implemented this - maybe you want to merge it. It doesn't do any harm and it does provide a new feature - it makes a marker file content available in the `Jenkinsfile` as a global variable.

llibicpep Could you clarify whether there's a bug in inline-pipeline or not? The last comment seems to indicate not, but I'd like to make sure. Thanks.

I am not entirely sure anymore danielbeck.

As a matter of fact - inline-pipeline plugin on its own does not mark in-progress status on SCM commits (and my PR does not fix that). Similar plugin pipeline-multibranch-defaults suffer from this as well. Turns out the `checkout scm` step is the one that usually does this, even though `checkout` step might not be among the very first steps in the pipeline. In my specific case I use `readTrusted` step to fetch configuration file and then comes a bunch of preparation steps - it's about 20-30 seconds into the pipeline before I do my first `checkout scm`, and all that time my users kept in the dark on the PR status page. So I think it's up to you wether you consider this a bug or not. It is certainly a user experience deficiency in my opinion.

Let me try to unpack my findings so you have full context.

For both github branch source and bitbucket branch source plugins there are two components for commit status notifications to being sent out - one is the `SCMRevisionAction` that both plugins are using to know commit ID notification must be sent to, but also `SCMListener#onCheckout` event that initiates notification routine.

Initially, when I opened this ticket, I thought it was just the `SCMRevisionAction` component. You can see the `SCMBinder` implementation of `FlowDefinition` does create `SCMRevisionAction` and this plugin's `InlineFlowDefinition` does not. I am not sure what the implication of that might be, other than what I have faced.

But then I've learned about `SCMListener#onCheckout` and with that info it became clear to me a simple workaround to this is to do `checkout scm` in my pipeline as earlier as possible even if I didn't need it there. I didn't immediately realized that due to another bug in Bitbucket plugin https://issues.jenkins.io/browse/JENKINS-66040 (it is very specific to it's implementation and has nothing to do with inline-pipeline). Otherwise, `checkout scm` would do both - set `SCMRevisionAction` as well as fire `SCMListener#onCheckout` event.

I personally think there must be another way plugins like inline-pipeline should be able to fire in-progress events. Maybe it should fire off `SCMListener#onCheckout` event even though it doesn't do a checkout? Or perhaps there must be new type of events on `SCMListener` that this plugin should fire and branch source plugins should listen? Something like `SCMListener#onRead`? Or maybe this new event must be fired off by steps like `readTrusted` and also `SCMFileSystem` API? I've created https://issues.jenkins.io/browse/JENKINS-66044 to discuss this. I'd appreciate if you can weight in your opinion in there.

As to my PR - it is not directly related to this ticket. Since I started looking into this I've added a new unrelated feature - a `markerFile` global env variable that would expose contents of the marker file. Same can be achieved by just using the `readTrusted` step, but inline Jenkinsfile somehow needs to know what marker file name was used. As a side effect - this implementation will actually create `SCMRevisionAction`, so indirectly it is related. I also just thought it would be nice to expose a marker file name as well next to its content.