-
New Feature
-
Resolution: Unresolved
-
Critical
Persisting build(s) log(s) in MySQL (or similar) will make Jenkins updates much easier to manage.
In fact, when build logs change their format we sometimes end up with a broken system which it is often unable to read logs of old builds. Software changes even break stored builds info from time to time
- is related to
-
JENKINS-38313
External Build Log storage for Jenkins
-
- In Progress
-
[JENKINS-26545] Persist build(s) log(s) in MySQL (or similar)
Libero Scarcelli
created issue -
Libero Scarcelli
made changes -
| Description |
Original:
Persisting build(s) log(s) in MySQL (or similar) will make Jenkins updates much easier to manage. In fact, when build logs change their format we end up with a broken system which it is often unable to read logs of old builds. Sometimes software changes even break stored builds info |
New:
Persisting build(s) log(s) in MySQL (or similar) will make Jenkins updates much easier to manage. In fact, when build logs change their format we sometimes end up with a broken system which it is often unable to read logs of old builds. Software changes even break stored builds info from time to time |
| Assignee | Original: Praqma Support [ praqma ] | |
| Resolution | New: Won't Fix [ 2 ] | |
| Status | Original: Open [ 1 ] | New: Resolved [ 5 ] |
Libero Scarcelli
added a comment - Ok... first of all... how to correctly back that stuff up? On Windows copying all those links is a problem, some back up systems run into issues trying to copying those links.
Then what if a code change breaks build logs? You will end up with a completely broken system. And this is happening on Windows...
Libero Scarcelli
added a comment - Ok... first of all... how to correctly back that stuff up? On Windows copying all those links is a problem, some back up systems run into issues trying to copying those links.
Then what if a code change breaks build logs? You will end up with a completely broken system. And this is happening on Windows... Libero Scarcelli
added a comment - Ok... first of all... how to correctly back that stuff up? On Windows copying all those links is a problem, some back up systems run into issues trying to copying those links.
Then what if a code change breaks build logs? You will end up with a completely broken system. And this is happening on Windows...
Libero Scarcelli
added a comment - Ok... first of all... how to correctly back that stuff up? On Windows copying all those links is a problem, some back up systems run into issues trying to copying those links.
Then what if a code change breaks build logs? You will end up with a completely broken system. And this is happening on Windows... Libero Scarcelli
made changes -
| Resolution | Original: Won't Fix [ 2 ] | |
| Status | Original: Resolved [ 5 ] | New: Reopened [ 4 ] |
Mads Nielsen
added a comment - Why did you put this under the logging-plugin component? The logging-plugin has nothing to do with this core change?
Mads Nielsen
added a comment - Why did you put this under the logging-plugin component? The logging-plugin has nothing to do with this core change? Because after modifying the Core you might want to modify the logging-plugin as well in order to extend it using new functionality... But yes... it's not necessary
Libero Scarcelli
added a comment - - edited Because after modifying the Core you might want to modify the logging-plugin as well in order to extend it using new functionality... But yes... it's not necessary On Windows copying all those links is a problem, some back up systems run into issues trying to copying those links.
In other words, you want Jenkins to not use OS features because your crap software doesn't support them. Well, if you prohibit creation of symbolic links on Windows through Group Policy, Jenkins will not create them.
Then what if a code change breaks build logs?
You're still incredibly vague.
Please note that build logs in Jenkins are simple text files. They cannot break (unless moving to a completely different architecture like IBM's servers, I suppose). Please mind your terminology, otherwise communication will be incredibly difficult.
As to code changes making parts of build records unloadable (including disabling plugins that store data in configuration or build records), that's handled by Old Data Monitor. You can discard these plugins' data. For deliberate code changes, plugin authors can write backward compatibility code to transform old data into a new format.
So what exactly is the problem you're trying to solve, and how is a database supposed to solve it?
A major architectural change like this needs to be discussed on the dev list.
FWIW a more exhaustive description of failure modes in the current system is needed – right now it's not clear at all what the problem is, or how use of a database would help.