It does not suite my needs, it just allows to organize multiple jobs
which are supposed to all be triggered by the same event, am I
correct?
My jobs are pretty similar to each other - ex. build jobs have the
same configuration except svn url, downstream jobs list and maybe some
details (like email
Hey,
Checkout the environmental variable here:
https://wiki.jenkins-ci.org/display/JENKINS/Building+a+software+project
Short answer:
echo ${JOB_NAME}
echo ${BUILD_NUMBER}
On Friday, November 16, 2012 3:39:26 PM UTC-5, Martin Lichtin wrote:
>
> Hi
> For a parameterized build with one "run par
I also think using the fingerprint plugin
(https://wiki.jenkins-ci.org/display/JENKINS/Fingerprint) will be very useful
to track dependencies - i.e. this build failed because these dependencies are
not compatible...
Mark,
History. At this time, I report outward so that we can determine which
tests are flaky. That's the engineering reason.
We all know the MGMT reason...
Metrics , Metrics, Metrics
Total result trendlines are useful. I just wish I could click on a
specific test and see its history
This may sound "heretical", but it seems like that is too much process for a
compilation failure or a test failure. If the code fails to compile, don't you
most want to fix the failed compilation? Why make the person who is fixing the
failed compilation also spend time updating another databas
You could probably use the groovy post build action plugin and make a script to
send a request using whatever API your ticket system uses.
Sent from my iPhone
On 2012-11-17, at 3:31 PM, Gustavo Lira e Silva wrote:
> How can I implement to Jenkins open or close a issue ticket?
>
> I can use Re
How can I implement to Jenkins open or close a issue ticket?
I can use Redmine, Trac, Mantis, Bugzilla, whatever. It`s possible to
jenkins open a Issue ticket on some of this projects?
If possible I would like open a Issue ticket (some of these softwares) and
jenkins closse the issue depending of
*pretty cheap
Another problem caused by not using the "Block build when upstream project is
building" or "Block build when downstream project is building" in my post setup
is that Job A and Job B could end up running on the same slave. This would be
problematic (for me at least) since the artefacts of Job A
I'm also new here - but possibly facing similar problems (C#). I'm not sure
how exactly you expect the dependencies to be "handled", but I thought I would
post my opinion.
I am going for your option B "one job for each project?"
My current plan is to add "build other project" "post build tasks
10 matches
Mail list logo
