https://issues.jenkins-ci.org/browse/JENKINS-45970
this might cover it already :)
On Monday, March 4, 2019 at 5:02:43 PM UTC, Brian J. Murrell wrote:
>
> On Mon, 2019-03-04 at 15:28 +0100, Baptiste Mathus wrote:
> > This seems like a useful thing. I would recommend filing an issue in
> > https:
It would definitely be my preferred way of building code, but unfortunately
the Jenkins master has to clone and perform the merge per pipeline every
time. That doesn't scale on a sizeable repo with many active PRs and 12
multibranch pipelines :(
I've seen people merge PRs with an old base befor
I'm not sure what's available for Gitlab, but some other SCMs have a plugin
that allows commits by certain authors be skipped/ignored.
https://github.com/jenkinsci/scm-trait-commit-skip-plugin for example.
If there is no such plugin for Gitlab, it might be easy enough to make one
or contribute a
On Friday, February 1, 2019 at 12:04:26 AM UTC, Daniel Becroft wrote:
>
> We had a similar issue, and it ended up being related to MSBuild itself,
> not Jenkins. The jobs seemed to work correctly when run from a command
> line, but it took a while and they eventually started failing as well.
>
On Thursday, January 31, 2019 at 4:45:40 PM UTC, Simon Richter wrote:
>
>
> There are a few things going on:
>
> - MSBuild sticks around after a build if the same project is rebuilt
> - Jenkins kills processes belonging to a build after it believes the
> build has finished
> - MSBuild has
After updating Jenkins with plugins from early April 2018, I'm seeing
inconsistent failures in my pipelines' calls to MSBuild which I cannot
reproduce outside of Jenkins. It occurs in both powershell and bat steps.
The error presents as
0>MSBUILD : error MSB4166: Child node "14" exited premat
Nothing released yet, but there are some relevant JEPs that might interest
you
https://github.com/jenkinsci/jep/blob/master/jep/207/README.adoc
https://github.com/jenkinsci/jep/blob/master/jep/210/README.adoc
https://github.com/jenkinsci/jep/blob/master/jep/212/README.adoc
On Monday, October 22,
You can set the status on a github multibranch pipeline using
the https://github.com/jenkinsci/github-scm-trait-notification-context-plugin
It does not require anything in the scripted pipeline/Jenkinsfile, it is
added on the multibranch pipeline configuration as a behavior (where the
branch / P
a sample build
> step look for the scan operation?
>
> -aps
>
> On Sat, Aug 18, 2018 at 10:47 AM Steven Foster > wrote:
>
>> You can use the "build" step to start a multibranch scan. Just call it on
>> the multibranch job as you would a normal job.
>>
You can use the "build" step to start a multibranch scan. Just call it on
the multibranch job as you would a normal job.
On Friday, August 17, 2018 at 4:29:24 PM UTC+1, pisymbol wrote:
>
> I have a job that creates a new branch/tag in SVN. IT does so by modifying
> some internal build files and
I haven't used it, but perhaps the Node Sharing Plugin would help here?
https://wiki.jenkins.io/display/JENKINS/Node+Sharing+Plugin
--
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 i
It might be rebuilding because the daily repo scan sees that the target
branch has been changed (e.g. master). I'm not sure why the manual scan
wouldn't see this, too.
I'm using github branch source and had this issue, so it might be different
in bitbucket but the repo scan log should mention s
I'm encountering problems with the PR Merge Jenkinsfile checkout since my
build is actually 12 builds in parallel so the pressure is enormous
especially when multiple prs are building at once. I would like to use the
reference repository feature on the master to relieve this somewhat, but I
hav
If you end up managing your own status notifications, you might want to
either use the same "context"/"label" as the automatic multibranch
notifications (so it is overwritten) or disable the automatic ones and
manage it entirely yourself.
https://plugins.jenkins.io/github-scm-trait-notification
I think with the declarative syntax all of the "scaffolding" (stages, post,
when) bits have to be set in stone.
This recent thread might be slightly relevant
https://groups.google.com/forum/#!topic/jenkinsci-users/E-3O1rHWkdM
On Tuesday, April 3, 2018 at 11:14:51 PM UTC+1, Arnaud Brunet wrote:
>
s a flag to request a shallow
>> clone. This reduces the fetch time very significantly.
>>
>> On Wed, Mar 28, 2018, 18:03 Steven Foster > > wrote:
>>
>>> Is there an alternative to a full checkout on the master to determine
>>> the merge result of a
Is there an alternative to a full checkout on the master to determine the
merge result of a Jenkinsfile for PR merge builds in a multibranch project?
Specifically using github. I'm finding the full checkout seems to strain
the whole system when the master needs to check out a large repo ~15 time
On Tuesday, March 13, 2018 at 1:02:02 PM UTC, Sverre Moe wrote:
>
> Looks like there is a fix for this in the works.
> https://github.com/jenkinsci/lockable-resources-plugin/pull/70
>
I *think* this fix is just for manual reservation/unreservation of a
resource by a user (there's a button in the
Nevermind me, I'm a liar. When I added the aggregate build I also switched
from a branch build to a PR-Merge build, which necessitates a full checkout
to properly resolve the Jenkinsfile I suppose
On Friday, March 9, 2018 at 5:27:37 PM UTC, Steven Foster wrote:
>
> Hi there,
>
I think it's a feature of declarative syntax rather than multibranch. In
declarative, every time a node is allocated it comes with a checkout scm by
default.
On Monday, March 12, 2018 at 12:50:53 PM UTC, Behrang wrote:
>
> In my pipeline I don't have this step and everything is working fine, but
Hi there,
I'm using a pattern of split pipelines due to the number of parallel tasks
needed and the grouping between them. I have an aggregating "parent"
pipeline that kicks off indexing for all of the sub-builds (which are
multibranch pipelines) then kicks off the sub-builds themselves.
The a
env.BRANCH_NAME is only populated when your job is from a Multibranch
Project type (which is probably a good project type to use for this kind of
building)
On Wednesday, January 17, 2018 at 10:45:53 AM UTC, Hiesgen, Raphael wrote:
> Thanks for the pointer! So, the recommended way is my third op
I'm trying to figure out the best way to organize some Jenkins multibranch
builds. I have 2 dimensions of parallel work in platforms and platform
configurations. Currently, as a simplest solution, I use a single build
with a flattened parallel list. This gets the job done but it makes it
diffic
; If github receives a duplicate context label it just replaces the
> existing one, so this is helpful if you are doing more than one kind of
> build for a repo.
>
> That explains it! That's so frustrating :( . Thanks for your help!
>
>
> On Thursday, January 4, 2018 at 11:24:39
Here is the repo for the custom github context
plugin https://github.com/steven-foster/github-scm-trait-notification-context
I still need to actually release it to the plugin center, hopefully that's
not too arduous.
It lets you specify a context label for a multibranch project
I am using Git though, I'm not sure about the current availability of this
functionality for SVN
--
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-user
I have been using the multibranch project's tag build functionality to
achieve this. An environment variable is provided when running a tag build,
so the pipeline can have a stage which checks for the presence of that
variable.
Using multibranch to build a single branch seems a little counter
i
I think you can get that with this:
when {
expression {
env.TAG_NAME != null
}
}
You get the env.TAG_NAME from the branch api when it's a tag build.
A shortcut would be helpful, I suggested it
here https://issues.jenkins-ci.org/browse/JENKINS-48523
On Wednesday, December 20, 20
You should define the parameters in the pipeline also:
https://jenkins.io/doc/book/pipeline/syntax/#parameters
currently there is some disconnect in the project configuration UI for
pipeline jobs, many of the options there need to actually be defined in the
pipeline.
On Wednesday, September 20,
Figured out the issue.
In order to manage Webhooks, the branch job must have:
a. run at least once
b. contain at least one scm checkout
In my simple testing neither of those cases were true, leading me to go
round in circles for awhile :)
I suspect the request to manage from the branch source pl
On Friday, September 1, 2017 at 11:57:32 AM UTC+1, Stephen Connolly wrote:
>
> The credentials provided for manage hooks needs to have permission to
> manage hooks on all repositories.
>
> You may need to trigger the "Re-register hooks for all jobs" if something
> went wrong.
>
> HTH
>
Still s
On Thursday, August 31, 2017 at 5:55:27 PM UTC+1, Stephen Connolly wrote:
>
>
> Periodic randomly levels all jobs
>
The specs on my 30m interval jobs are all H/2 * * * *, doesn't this mean
every 2 minutes rather than every 30 minutes which would be H/30 * * * *?
Or is the internal system differ
On Friday, September 1, 2017 at 12:18:35 AM UTC+1, Stephen Connolly wrote:
>
>
> Well what it means is that to have hooks automatically managed at the repo
> level you need to define the GitHub servers in the global config, enable
> managing hooks and provide credentials that can manage hooks (
On Thursday, August 31, 2017 at 5:55:27 PM UTC+1, Stephen Connolly wrote:
>
> Periodic randomly levels all jobs
>
Ah, my mistake. What I was noticing was a symptom of something else (user
error)
--
You received this message because you are subscribed to the Google Groups
"Jenkins Users" group.
About scan repository triggers, I generated multibranch jobs with a jobDSL
and replaced "periodic" with "cron" to avoid a huge amount of indexing
happening at once. Is that supposed to even be an option? Since it's not in
the configuration UI.
--
You received this message because you are subsc
Hi,
Multibranch pipeline jobs do not automatically configure Github webhooks,
right?
It's necessary to set up the Jenkins (github plugin) service on the Github
repo and add the Jenkins user as a collaborator?
Just wanted to make sure my understanding was correct before I give people
the wrong
This workaround is a good idea, unfortunately it wouldn't work for us
because of the amount of PRs. I ended up extending the github branch source
plugin to let me filter based on this property. Not sure how to go about
contributing this back, or if it's even a feature that would be welcomed.
On
Ok, so the functionality to filter based on a PRs base branch isn't there?
For the branch portion, I'm able to make it build only the branch I want.
But with PRs, it seems to be all or nothing. In my case there are hundreds
of PRs and I'm only interested in building a select few based on a specif
Does the Github multibranch source allow filtering for PRs that target a
particular base branch?
So I want to build only branch 'foo/bar' and all PRs that are targeting
'foo/bar'
--
You received this message because you are subscribed to the Google Groups
"Jenkins Users" group.
To unsubscribe
I do like this solution and it seems really flexible but unfortunately it
has one big problem for us. The build is not technically *done* until this
input step is answered. Sometimes we will want to release over a week
later. We release at any time really. If we timeout then we can't answer
the
On Tuesday, August 15, 2017 at 6:09:04 PM UTC+1, Simon Richter wrote:
>
>
> You are looking for the "Promoted Builds" plugin.
>
>
Ah, I did come across this but unfortunately we are using pipeline builds
and it seems this isn't compatible
--
You received this message because you are subscribed
Hello,
Does anyone know of any techniques or plugins for triggering a release
after a build? I'd like to be able to decide to release any previous build
and have that process traceable. Input steps don't suit because it holds
back the build feedback. Sometimes it will be a few days after a buil
42 matches
Mail list logo
