You need 99 jobs for the 99 programs, but what about the libraries? I
assume a program will depend on one or more libraries. Are there
dependencies between libraries? (this is common and not a problem if it is
understood.) Are there dependencies between programs? (this would be bad.)
How fast is your job if there are no changes? Are the artifacts available
so that the build system detects that nothing needs to be done quickly? If
so, then you could consider a single jenkins job that iterated over the
libraries in the correct order and then over the programs. This would by
default use a single workspace. It has the advantage of only scanning each
library once.
otherwise....there is actually nothing that says the build has to use the
workspace checked out by jenkins. I suspect your predecessor had extra
workspaces that he reused for every build. Have you found these so you know
they exist? Are there containers involved? It's possible the workspaces
are not getting mounted inside the container.
If you are forced to have many jenkins jobs, then I would put a JenkinsFile
in every program dir. whether they are scripted or declarative is up to
you. I like scripted so much I rewrote everything my predecessor did
because he used all declarative (and had terrible program structure).
As far as ${EXECUTOR_NUMBER} not getting expanded, this could be an issue
of timing. It's possible that whatever process is doing that expansion is
before an executor is chosen. But the expansion in a script. Like I said,
the build doesn't have to use the workspace created by jenkins.
On Wednesday, August 19, 2020 at 6:47:23 PM UTC-4 Anton Shepelev wrote:
> jeremy mordkoff:
>
> > I'm having a little trouble understanding exactly what you
> > are asking.
>
> I am sorry for an insufficiently clear description. Let me
> try again.
>
> Since our .NET projects are highly interdependent, we
> maintain them in a single SVN repository with a strucure
> like this:
>
> trunk
> programs
> program1
> program2
> ...
> program99
> library
> library1
> library2
> ...
> library999
>
> where each program depends on one of more libraries. I want
> to create 99 Jenkins items, using declarative pipelines,
> each building one of the 99 programs. We have several nodes
> registered on different machines with different
> environments. I want each node to checkout the SVN trunk
> exactly once and use that working copy in each pipeline to
> build each individual program. I do not understand how to
> set it up in Jenkins because each pipeline seems to use its
> own SVN working directory.
>
> The current configurtion, setup by a previous maintainer,
> relies on the Jenkins MSBuild plugin, and manages somehow to
> retain a single SVN working direcotory per node and
> executor, whose name is stored in a Jenkins global property
> SVN_REPO with the value `ExecutorRepo_${EXECUTOR_NUMBER}.'
> When I tried to specify this property in the "Local module
> directory" for the pipeline, the `${EXECUTOR_NUMBER}' part
> was left unexpanded in the actual path to the SVN working
> directory. I don't understand how and why it is expanded
> with the MSBuild plugin but is not with the declarative
> pipeline.
>
> > I think you are asking if it is possible to trigger
> > multiple builds in a single workspace.
>
> Yes.
>
> > If you use a single pipeline, this is trivial.
>
> As I said above, I prefer one pipeline per program, for the
> convenience of having a dedicated page on the Jenkins web-
> interface for each project and the ability to change the
> settings for building individual projects independently of
> other projects. It this can be achieved with a single
> pipelike, I should like to know how.
>
> > So perhaps you should consider writing a single pipeline
> > that iterates over all libraries and projects and builds
> > each one in turn.
>
> Is such iteration possible with the declarative syntax, or
> shall I switch to the scripted pipeline?
>
>
--
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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/jenkinsci-users/243532db-2a12-499b-994c-eabb9c67b58bn%40googlegroups.com.
