I found the version from Pawel has problems if you are checking out the pipeline from SCM (not embedded in Jenkins job UI config). This is my version for those cases:

node {
    def scriptFolder = sh(script: "echo \$(pwd | sed 's,\\(.*\\)\\(@[0-9]*\$\\),\\1,')@script/\$(sed -n '2,\$p' ../config.xml | xmllint --xpath '(//scriptPath/text())' - | xargs dirname)", returnStdout: true).trim()
    sh("cd ${scriptFolder} && ls -l vars/ && if [ -d .git ]; then rm -rf .git; fi; git init && git add --all . && git commit -m init &> /dev/null")
    library identifier: 'local-lib@master', retriever: modernSCM([$class: 'GitSCMSource', remote: scriptFolder])

    stage('Build') {
        log.info("called shared lib") // use the loaded library
    }
}

For these cases, the pipeline itself is checkout out in a different workspace (same directory name but with @script in the name) than what the pipeline itself defines.

I've successfully tested a simple workaround for GIT repos having both protocols - HTTPS and SSH (I'm using BitBucket) - just configure the Jenkins job as follows (pointing to the same repository but forcing different fetch methods):

• In the Branch Sources add "Checkout over SSH" option

• In the Pipeline Libraries -> Source Code Management -> Project Repository use HTTPS protocol - e.g. something like https://...

Is there a way to import code into the Jenkinsfile from the local repository (other than the load step)?

Is there a way (or workaround) to create a shared library in the same repository as the Jenkinsfile and import this library into the Jenkinsfile?

Yes. Provided that the "directory structure of a Shared Library repository" is observed according to specification, then it's absolutely feasible and no workaround is required to get it working. Basically, your directory structure would require an adjustment along the following lines:

+- src                     # Groovy source files
|   +- org
|       +- foo
|           +- Bar.groovy  # for org.foo.Bar class
+- vars
|   +- foo.groovy          # for global 'foo' variable
|   +- foo.txt             # help for 'foo' variable
+- resources               # resource files (external libraries only)
|   +- org
|       +- foo
|           +- bar.json    # static helper data for org.foo.Bar
+- someModule
|   +- ...
|
|
+- Jenkinsfile

This answer is not based on a conjecture. Although it's not documented, I have applied this pattern on multiple projects and training, and it works. You do not need to tinker with your job configuration in anyway than is usual.

My shared library pipeline can test itself. It's a bit clunky but it works.

All I do is import the library itself into the Jenkinsfile in the library's repo. The actual pipeline is defined in /vars as myPipeline.groovy - it's in Declarative syntax, uses the Delegate pattern provided by Jenkins to ingest parameters, and every effort is made to put all actual code into library steps, leaving the pipeline DSL as clean as possible.

// repo's Jenkinsfile
library 'my-shared-library'

myPipeline {
  myParam1 = 'value1'
  myParam2 = 'value2'
}

It's important to remember to pull the branch you're working on when you're testing something new:

// repo's Jenkinsfile
library 'my-shared-library@my-new-branch`
...

You can write actual unit tests into the /test/com/myOrg/ dir; I use the plain JenkinsPipelineUnit framework, it gets the job done, but it's clunky. I landed on using Gradle to perform the build and tests. It's slow, but gets the job done.

Or, you can test your /vars steps in the actual Jenkinsfile in an ad-hoc pipeline. This is sometimes easier than dealing with mocking everything out in units, especially if you end up mocking what you want to be testing, which defeats the purpose.

load() should definitely be providing the loaded scripts for editing in Replay. If not, something else is going on.

Lastly, I highly recommend setting up a Jenkins instance on your dev machine, so you can test changes without pushing them. Especially if you create an ad-hoc pipe to test your steps, you can then edit the pipeline in Replay, creating the shortest feedback loop for yourself. To get even faster, get familiar with testing groovy in the Script Console, or using Gradle run to actually run more complex code from the command line. Anything to avoid waiting for code to push and pipelines to run will make your development go faster.

note of warning on the script console, readJson/readYaml don't work right, and I'm sure others too. When i need to test stuff like that, i tend to use ad-hoc pipes to quickly iterate on the code.