Glad you're using Jenkins and declarative pipeline. You may want to spend
an hour watching a Declarative Pipeline video that Kohsuke Kawaguchi hosted
with Tyler Johnson and me presenting some ideas that make it easier to
succeed with declarative pipeline.
Specific comments are placed inline.
On Tue, May 19, 2020 at 8:31 AM Pete Kane <p...@pjksolutions.com> wrote:
> Hi Mark, thanks for replying I should of mentioned I'm a newbie to Jenkins
> so your examples are a tad overwhelming :-) I actually got Jenkins to build
> successfuly but it aint pretty.
>
> pipeline{
>> agent any
>> environment {
>> APIproject = "./MyAPI//API.csproj"
>> APIPublishPath = "//home//myname//Jenkins//Linux-ARM64//"
>> Commonproject = "./Common.csproj"
>> CommonPublishPath =
>> "//home//myname//Jenkins//Linux-ARM64//Common//"
>> }
>>
>> stages{
>> stage('Checkout Common') {
>> steps {
>> git 'g...@github.com:myname/Common.git'
>>
>
Since you're using declarative pipeline, there is an implied checkout that
happens already. You don't need this 'git' step because declarative
pipeline already assumed you would want a checkout and performed the
initial checkout into the workspace.
Calling the git step at this location did not harm you, it just performed
another 'fetch' (or two) that had been done only seconds before.
>
>> }
>> }
>>
>> stage('Build Common'){
>> steps{
>> sh "dotnet build ${env.Commonproject} -c Release -r linux-arm64 -o
>> ${env.CommonPublishPath}"
>> }
>> }
>> stage('Checkout API') {
>> steps {
>> dir('API')
>> {
>> git 'g...@github.com:myname/API.git'
>>
>
The 'git' step has been superseded by the more powerful and more capable
'checkout' step. The Jenkins pipeline syntax generator (
https://your-jenkins.example.com/pipeline-syntax ) will allow you to
define the configuration you want and then generate the syntax you should
use. I believe that video clip includes a section on the pipeline syntax
generator.
Since this is using 'ssh' protocol to access the git repository
(g...@github.com:xx/yy.git), you should define a Jenkins credential which
includes the private key used to access that repository. Then reference
that credential in this context. If you don't do that, then all the agents
will need to be configured to silently allow ssh access to the GitHub
repository. That works for small installations but does not work well for
medium size or large installations.
Thanks,
Mark Waite
--
You received this message because you are subscribed to the Google Groups
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/jenkinsci-users/CAO49JtGuTmibrGp2y%3DZcgk7J1staPQSk8yoX8Y%2BmA9rFd3X5Ew%40mail.gmail.com.
