Jenkins builds not properly preserving artifacts?
Guys - Iâve noticed that when a build completed on the Inria infrastructure, for a short time the console output correctly shows all the artefacts that were used to create that build - e.g. the slices loaded etc. However after a short time - the output then reverts to something like below (which isnât as useful): Started by upstream project "[8mha:AAAAqh+LCAAAAAAAAP9b85aBtbiIQTGjNKU4P08vOT+vOD8â¦. originally caused by: [URLTrigger] A change within the response URL invocation (log) Building remotely on pharo-contribution-winxp in workspace C:\builds\workspace\PharoLauncher Deleting project workspace⦠done --- Iâve looked at a few other jobs (I noticed this for Pharo Launcher) and they seem the same. I think the jobs arenât configured properly? - As normally (at least in other languages like Java), the intent is that the console output reflects what was on the console when the job was run. I have a hunch that something is overwriting these files before they are archived away. As we donât seem to have other details of what went into a build job (which is another issue - I would expect the changes page for a build to also show this info in a better format). Do you think this could be fixed? tim
On 02.09.2014, at 00:41, Tim Mackinnon <tim@testit.works> wrote:
Guys - Iâve noticed that when a build completed on the Inria infrastructure, for a short time the console output correctly shows all the artefacts that were used to create that build - e.g. the slices loaded etc. However after a short time - the output then reverts to something like below (which isnât as useful):
Started by upstream project "[8mha:AAAAqh+LCAAAAAAAAP9b85aBtbiIQTGjNKU4P08vOT+vOD8â¦. originally caused by: [URLTrigger] A change within the response URL invocation (log) Building remotely on pharo-contribution-winxp in workspace C:\builds\workspace\PharoLauncher
Deleting project workspace⦠done â
Not entirely sure but I think thatâs the fingerprint of the specific build that triggered the build youâre looking at. Fingerprints allow builds to reference other builds explicitly and to use artifacts from those builds (if configured correctly). That being said, I agree that the output doesnât help a human reader much...
Iâve looked at a few other jobs (I noticed this for Pharo Launcher) and they seem the same. I think the jobs arenât configured properly? - As normally (at least in other languages like Java), the intent is that the console output reflects what was on the console when the job was run. I have a hunch that something is overwriting these files before they are archived away.
As we donât seem to have other details of what went into a build job (which is another issue - I would expect the changes page for a build to also show this info in a better format).
That would require either - to write a dedicated log from within the image (which could probably be done with a dedicated package that you could load) or - saving all artifacts (like packages, configurations etc.) in the workspace (taks up a huge amount of space). Iâm not sure that thereâs a simple general solution at this time⦠Cheers, Max
Do you think this could be fixed?
tim
The job is a matrix build... the outer job just triggers the matrix builds (see the link "default",), the log is there: https://ci.inria.fr/pharo-contribution/job/PharoLauncher/890/PHARO=30,VERSIO... On Tue, Sep 2, 2014 at 12:41 AM, Tim Mackinnon <tim@testit.works> wrote:
Guys - Iâve noticed that when a build completed on the Inria infrastructure, for a short time the console output correctly shows all the artefacts that were used to create that build - e.g. the slices loaded etc. However after a short time - the output then reverts to something like below (which isnât as useful):
Started by upstream project " [8mha:AAAAqh+LCAAAAAAAAP9b85aBtbiIQTGjNKU4P08vOT+vOD8â¦. originally caused by: [URLTrigger] A change within the response URL invocation (log <https://ci.inria.fr/pharo-contribution/job/PharoLauncher/884/triggerCauseAct...>) Building remotely on pharo-contribution-winxp <https://ci.inria.fr/pharo-contribution/computer/pharo-contribution-winxp> in workspace C:\builds\workspace\PharoLauncher
Deleting project workspace⦠done
---
Iâve looked at a few other jobs (I noticed this for Pharo Launcher) and they seem the same. I think the jobs arenât configured properly? - As normally (at least in other languages like Java), the intent is that the console output reflects what was on the console when the job was run. I have a hunch that something is overwriting these files before they are archived away.
As we donât seem to have other details of what went into a build job (which is another issue - I would expect the changes page for a build to also show this info in a better format).
Do you think this could be fixed?
tim
-- -- Marcus Denker -- denker@acm.org http://www.marcusdenker.de
Marcus - how do you navigate to that view from the Build #890 of PharoLauncher? When I click on the link you show - thats that output I first saw in the console from the list of builds for Pharo Launcher (which is what I was looking for) - and when I click on âBack To Projectâ it takes me to the 890 build results page - however if I was looking at build 889 - where on that page do I click to see that output? I think if I understand that - this would give the information we would expect - and then we can either document this, or maybe put some artefact in every build (via a script) that lets people easily navigate to see what a build was composed off (as it seems that the info is there). Tim On that page, On 2 Sep 2014, at 09:14, Marcus Denker <marcus.denker@inria.fr> wrote:
The job is a matrix build... the outer job just triggers the matrix builds (see the link "default",), the log is there:
https://ci.inria.fr/pharo-contribution/job/PharoLauncher/890/PHARO=30,VERSIO...
On Tue, Sep 2, 2014 at 12:41 AM, Tim Mackinnon <tim@testit.works> wrote: Guys - Iâve noticed that when a build completed on the Inria infrastructure, for a short time the console output correctly shows all the artefacts that were used to create that build - e.g. the slices loaded etc. However after a short time - the output then reverts to something like below (which isnât as useful):
Started by upstream project " [8mha:AAAAqh+LCAAAAAAAAP9b85aBtbiIQTGjNKU4P08vOT+vOD8â¦. originally caused by: [URLTrigger] A change within the response URL invocation (log) Building remotely on pharo-contribution-winxp in workspace C:\builds\workspace\PharoLauncher
Deleting project workspace⦠done ---
Iâve looked at a few other jobs (I noticed this for Pharo Launcher) and they seem the same. I think the jobs arenât configured properly? - As normally (at least in other languages like Java), the intent is that the console output reflects what was on the console when the job was run. I have a hunch that something is overwriting these files before they are archived away.
As we donât seem to have other details of what went into a build job (which is another issue - I would expect the changes page for a build to also show this info in a better format).
Do you think this could be fixed?
tim
-- -- Marcus Denker -- denker@acm.org http://www.marcusdenker.de
On 02 Sep 2014, at 11:41, Tim Mackinnon <tim@testit.works> wrote:
Marcus - how do you navigate to that view from the Build #890 of PharoLauncher? When I click on the link you show - thats that output I first saw in the console from the list of builds for Pharo Launcher (which is what I was looking for) - and when I click on âBack To Projectâ it takes me to the 890 build results page - however if I was looking at build 889 - where on that page do I click to see that output?
It is not nice⦠But something is strange in the setup: it only runs on windows and does not show good names. The Pharo build looks better: https://ci.inria.fr/pharo/job/Pharo-4.0-Update-Step-2.1-Validation-A-L/ No idea, needs to be configures somehow⦠Jenkins is not that âniceâ from the UI as it targets developers who get used to it somehow.
I think if I understand that - this would give the information we would expect - and then we can either document this, or maybe put some artefact in every build (via a script) that lets people easily navigate to see what a build was composed off (as it seems that the info is there).
Tim
On that page, On 2 Sep 2014, at 09:14, Marcus Denker <marcus.denker@inria.fr> wrote:
The job is a matrix build... the outer job just triggers the matrix builds (see the link "default",), the log is there:
https://ci.inria.fr/pharo-contribution/job/PharoLauncher/890/PHARO=30,VERSIO...
On Tue, Sep 2, 2014 at 12:41 AM, Tim Mackinnon <tim@testit.works> wrote: Guys - Iâve noticed that when a build completed on the Inria infrastructure, for a short time the console output correctly shows all the artefacts that were used to create that build - e.g. the slices loaded etc. However after a short time - the output then reverts to something like below (which isnât as useful):
Started by upstream project " [8mha:AAAAqh+LCAAAAAAAAP9b85aBtbiIQTGjNKU4P08vOT+vOD8â¦. originally caused by: [URLTrigger] A change within the response URL invocation (log) Building remotely on pharo-contribution-winxp in workspace C:\builds\workspace\PharoLauncher
Deleting project workspace⦠done ---
Iâve looked at a few other jobs (I noticed this for Pharo Launcher) and they seem the same. I think the jobs arenât configured properly? - As normally (at least in other languages like Java), the intent is that the console output reflects what was on the console when the job was run. I have a hunch that something is overwriting these files before they are archived away.
As we donât seem to have other details of what went into a build job (which is another issue - I would expect the changes page for a build to also show this info in a better format).
Do you think this could be fixed?
tim
-- -- Marcus Denker -- denker@acm.org http://www.marcusdenker.de
Le 2 sept. 2014 à 12:53, Marcus Denker a écrit :
On 02 Sep 2014, at 11:41, Tim Mackinnon <tim@testit.works> wrote:
Marcus - how do you navigate to that view from the Build #890 of PharoLauncher? When I click on the link you show - thats that output I first saw in the console from the list of builds for Pharo Launcher (which is what I was looking for) - and when I click on âBack To Projectâ it takes me to the 890 build results page - however if I was looking at build 889 - where on that page do I click to see that output?
It is not niceâ¦
<Untitled 3.png>
But something is strange in the setup: it only runs on windows and does not show good names.
The Pharo build looks better:
https://ci.inria.fr/pharo/job/Pharo-4.0-Update-Step-2.1-Validation-A-L/
No idea, needs to be configures somehow⦠Jenkins is not that âniceâ from the UI as it targets developers who get used to it somehow.
The bad thing is that a matrix job is used instead of a standard job. Jenkins could manage that better but it would have been better to use the appropriate job. There is no reference to a windows build only.
Ah - yes, thatâs what I was missing. OK - the information is there (which is good). I will look in to how to document this - but I do wonder if we can do something cheap that makes it a bit easier to see this. Ideally, this information would be in the âChangesâ link for that build. I will have to look at a Java installation and refresh my memory and how things line up for them - my recollection was that if you have the ârightâ files in the right places - it populated things better (but Iâm not sure I ever saw a matrix build setup). It is true that Jenkins is a real beast - but I think I would prefer to spend energy on Pharo vs. contributing to Jenkins ;) Tim On 2 Sep 2014, at 11:53, Marcus Denker <marcus.denker@inria.fr> wrote:
On 02 Sep 2014, at 11:41, Tim Mackinnon <tim@testit.works> wrote:
Marcus - how do you navigate to that view from the Build #890 of PharoLauncher? When I click on the link you show - thats that output I first saw in the console from the list of builds for Pharo Launcher (which is what I was looking for) - and when I click on âBack To Projectâ it takes me to the 890 build results page - however if I was looking at build 889 - where on that page do I click to see that output?
It is not niceâ¦
<Untitled 3.png>
But something is strange in the setup: it only runs on windows and does not show good names.
The Pharo build looks better:
https://ci.inria.fr/pharo/job/Pharo-4.0-Update-Step-2.1-Validation-A-L/
No idea, needs to be configures somehow⦠Jenkins is not that âniceâ from the UI as it targets developers who get used to it somehow.
I think if I understand that - this would give the information we would expect - and then we can either document this, or maybe put some artefact in every build (via a script) that lets people easily navigate to see what a build was composed off (as it seems that the info is there).
Tim
On that page, On 2 Sep 2014, at 09:14, Marcus Denker <marcus.denker@inria.fr> wrote:
The job is a matrix build... the outer job just triggers the matrix builds (see the link "default",), the log is there:
https://ci.inria.fr/pharo-contribution/job/PharoLauncher/890/PHARO=30,VERSIO...
On Tue, Sep 2, 2014 at 12:41 AM, Tim Mackinnon <tim@testit.works> wrote: Guys - Iâve noticed that when a build completed on the Inria infrastructure, for a short time the console output correctly shows all the artefacts that were used to create that build - e.g. the slices loaded etc. However after a short time - the output then reverts to something like below (which isnât as useful):
Started by upstream project " [8mha:AAAAqh+LCAAAAAAAAP9b85aBtbiIQTGjNKU4P08vOT+vOD8â¦. originally caused by: [URLTrigger] A change within the response URL invocation (log) Building remotely on pharo-contribution-winxp in workspace C:\builds\workspace\PharoLauncher
Deleting project workspace⦠done ---
Iâve looked at a few other jobs (I noticed this for Pharo Launcher) and they seem the same. I think the jobs arenât configured properly? - As normally (at least in other languages like Java), the intent is that the console output reflects what was on the console when the job was run. I have a hunch that something is overwriting these files before they are archived away.
As we donât seem to have other details of what went into a build job (which is another issue - I would expect the changes page for a build to also show this info in a better format).
Do you think this could be fixed?
tim
-- -- Marcus Denker -- denker@acm.org http://www.marcusdenker.de
participants (4)
-
Christophe Demarey -
Marcus Denker -
Max Leske -
Tim Mackinnon