I take it back, not good workaround for me after all...
--
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 th
Not my case, but there is a trend of possible issues with community
feedback of each weekly versions on the download page :
https://jenkins.io/changelog/
Moreover, I would suggest you to install a LTS if you want a more stable
version of Jenkins.
2017-06-17 7:52 GMT+02:00 Kishore RP :
> Jenkins 2
I agree with Michael . Your upgrade pattern suggests that you're upgrading
at about the same frequency as the long term support release schedule
(quarterly) yet you're not receiving the benefits of the testing and fixing
which is done on the long term support releases.
For example, the 2.60.1 LTS
.You're correct that the git push needs to be wrapped in some form of
credentials.
Git checkouts in Jenkins can be done to the branch name of your choice,
including "match the branch name". Refer to the "Additional Behaviour"
called "Checkout to specific local branch". The online help for that
o
Thanks Mark. Since I'm using declarative pipeline in a Jenkinsfile in a
multi-branch job, UI option is kinda scarce and less relevant for me. So
anything that can be added to the declarative way of doing things is great.
The example you linked to is in scripted pipeline form, which I'm trying to
Oh, hm, interesting...
In my multibranch job I selected "GitHub" as the "Branch source"... for
"GitHub" there aren't many options... but for "Git" there are... and I
guess these play fine with Jenkinsfile...
Question.
Lets say I setup "Git" as the branch source and in my Jenkinsfile I set:
opti
Oh, hm, interesting...
In my multibranch job I selected "GitHub" as the "Branch source"... for
"GitHub" there aren't many options... but for "Git" there are... and I
guess these play fine with Jenkinsfile...
Question.
Lets say I setup "Git" as the branch source and add some "additional
options"
Another question, if I do customize "checkout", do I need to include
everything like in your example, or only what I want specifically, like
depth, and if nothing else is mentioned that the defaults are taken...?
--
You received this message because you are subscribed to the Google Groups
"Jen
Defaults are taken when values are not provided.
On Sat, Jun 17, 2017 at 11:19 AM Idan Adar wrote:
> Another question, if I do customize "checkout", do I need to include
> everything like in your example, or only what I want specifically, like
> depth, and if nothing else is mentioned that the d
it is possible to skipDefaultCheckout and then "checkout scm". this isn't
typically necessary or desirable if you want to operate on the same repo
where your Jenkinsfile lives, but it sounds like you might want to override
some checkout options, which seems cool. we also do this for some jobs th
Okay, so looks like what I should try in order to:
1. make checkouts faster
2. be able to git tag & push
Is the following:
1. Try with:
checkout(
extensions: [
[$class: 'CloneOption',
depth: 1,
shallow: true
]
]
)
2. Wait for Stephen...
BTW, I thought the sha
Hi Everyone,
Is there any way to get build number, build status and log information of
all upstream jobs of a build pipeline.
I have many jobs connected to each other. A triggers B, B triggers C. I
do not want to send success email for every project but want to send email
on last downstream
On Saturday, June 17, 2017 at 11:48:19 AM UTC-6, Idan Adar wrote:
>
> Okay, so looks like what I should try in order to:
> 1. make checkouts faster
> 2. be able to git tag & push
>
> Is the following:
>
> 1. Try with:
>
> checkout(
> extensions: [
> [$class: 'CloneOption',
> depth
- An intentionally narrow refspec (like
+refs/heads/master:refs/remotes/origin/master) reduces the objects copied
in the clone to only those in that refspec (typically the desired branch),
while still providing the full history of the working branch (but not the
history of o
BTW, this whole exercise is essentially only so that I could tag builds of
the master branch with 0.0.$BUILD_NUMBER so that I could record these as
"GitHub releases".
Naturally, if there is a simpler approach to create these releases/tags
instead of clone-tag-push, it'd simplify the whole proces
To pick this up again, i also tried to get this to work and ran into some
issues:
emailext (
subject: "subject",
body: """STARTED: Job '${env.JOB_NAME} [${env.BUILD_NUMBER}]':
${CHANGES, showPaths=true}
Check console output at "${env.JOB_NAME}
[${env.BUILD_NUMBER}],
16 matches
Mail list logo
