[JIRA] (OVIRT-1744) Revisit build artifact storage and retnesion

Tuesday, 7 November 2017

This is a multi-part message in MIME format...

------------=_1510041765-21211-504
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

     [
https://ovirt-jira.atlassian.net/browse/OVIRT-1744?page=com.atlassian.jir...
]

Barak Korren updated OVIRT-1744:
--------------------------------
    Description: 
We need to revisit how we store and manage build artifacts in our environment.

We need to do this to reach several goals:
# Stop having to frequently deal with running out of space on the Jenkins server
# Stop having to frequently deal with running out of space on the Resources server
# Make Jenkins load faster
# Make publishing of artifacts faster (If can take up to 20m to publish to
'tested' ATM)
# Make it so that finding artifacts is possible without knowing the exact details of the
job that made them. We would like to be able to find artifacts by at least:
#* Knowing the build URL in Jenkins
#* Knowing the STDCI stage/project/branch/distro/arch/git hash combination.
#* Asking for STDCI stage/project/branch/distro/arch/latest artifact

We need to achieve the above without significantly harming the UX we provide. For example,
users should still be able to find artifacts by navigating from links posted to
Gerrit/GitHub to the Jenkins job result pages.

  was:
We need to revisit how we store and manage build artifacts in our environment.

We need to do this to reach several goals:
# Stop having to frequently deal with running out of space on the Jenkins server
# Stop having to frequently deal with running out of space on the Resources server
# Make Jenkins load faster
# Make publishing of artifacts faster (If can take up to 20m to publish to
'tested' ATM)
# Make it so that finding artifacts is possible without knowing the exact details of the
job that made them is possible. We would like to be able to find artifacts by at least:
#* Knowing the build URL in Jenkins
#* Knowing the STDCI stage/project/branch/distro/arch/git hash combination.
#* Asking for STDCI stage/project/branch/distro/arch/latest artifact

We need to achieve the above without significantly harming the UX we provide. For example,
users should still be able to find artifacts by navigating from links posted to
Gerrit/GitHub to the Jenkins job result pages.

...
 Revisit build artifact storage and retnesion
 --------------------------------------------

                 Key: OVIRT-1744
                 URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1744
             Project: oVirt - virtualization made easy
          Issue Type: New Feature
          Components: Repositories Mgmt
            Reporter: Barak Korren
            Assignee: infra
            Priority: Highest
              Labels: artifacts, repositories

 We need to revisit how we store and manage build artifacts in our environment.
 We need to do this to reach several goals:
 # Stop having to frequently deal with running out of space on the Jenkins server
 # Stop having to frequently deal with running out of space on the Resources server
 # Make Jenkins load faster
 # Make publishing of artifacts faster (If can take up to 20m to publish to
'tested' ATM)
 # Make it so that finding artifacts is possible without knowing the exact details of the
job that made them. We would like to be able to find artifacts by at least:
 #* Knowing the build URL in Jenkins
 #* Knowing the STDCI stage/project/branch/distro/arch/git hash combination.
 #* Asking for STDCI stage/project/branch/distro/arch/latest artifact
 We need to achieve the above without significantly harming the UX we provide. For
example, users should still be able to find artifacts by navigating from links posted to
Gerrit/GitHub to the Jenkins job result pages. 

--
This message was sent by Atlassian Jira
(v1001.0.0-SNAPSHOT#100070)

------------=_1510041765-21211-504
Content-Type: text/html; charset="UTF-8"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

<html><body>
<pre>[
https://ovirt-jira.atlassian.net/browse/OVIRT-1744?page=com.atlassian.jir...
]</pre>
<h3>Barak Korren updated OVIRT-1744:</h3>
<pre>Description:</pre>
<p>We need to revisit how we store and manage build artifacts in our
environment.</p>
<p>We need to do this to reach several goals: # Stop having to frequently deal with
running out of space on the Jenkins server # Stop having to frequently deal with running
out of space on the Resources server # Make Jenkins load faster # Make publishing of
artifacts faster (If can take up to 20m to publish to &lsquo;tested&rsquo; ATM) #
Make it so that finding artifacts is possible without knowing the exact details of the job
that made them. We would like to be able to find artifacts by at least: #* Knowing the
build URL in Jenkins #* Knowing the STDCI stage/project/branch/distro/arch/git hash
combination. #* Asking for STDCI stage/project/branch/distro/arch/latest
artifact</p>
<p>We need to achieve the above without significantly harming the UX we provide. For
example, users should still be able to find artifacts by navigating from links posted to
Gerrit/GitHub to the Jenkins job result pages.</p>
<pre>was:</pre>
<p>We need to revisit how we store and manage build artifacts in our
environment.</p>
<p>We need to do this to reach several goals: # Stop having to frequently deal with
running out of space on the Jenkins server # Stop having to frequently deal with running
out of space on the Resources server # Make Jenkins load faster # Make publishing of
artifacts faster (If can take up to 20m to publish to &lsquo;tested&rsquo; ATM) #
Make it so that finding artifacts is possible without knowing the exact details of the job
that made them is possible. We would like to be able to find artifacts by at least: #*
Knowing the build URL in Jenkins #* Knowing the STDCI stage/project/branch/distro/arch/git
hash combination. #* Asking for STDCI stage/project/branch/distro/arch/latest
artifact</p>
<p>We need to achieve the above without significantly harming the UX we provide. For
example, users should still be able to find artifacts by navigating from links posted to
Gerrit/GitHub to the Jenkins job result pages.</p>
<blockquote><h3>Revisit build artifact storage and retnesion</h3>
<pre>     Key: OVIRT-1744
     URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1744
 Project: oVirt - virtualization made easy
         Issue Type: New Feature
         Components: Repositories Mgmt
Reporter: Barak Korren
Assignee: infra
Priority: Highest
  Labels: artifacts, repositories</pre>
<p>We need to revisit how we store and manage build artifacts in our environment. We
need to do this to reach several goals: # Stop having to frequently deal with running out
of space on the Jenkins server # Stop having to frequently deal with running out of space
on the Resources server # Make Jenkins load faster # Make publishing of artifacts faster
(If can take up to 20m to publish to &lsquo;tested&rsquo; ATM) # Make it so that
finding artifacts is possible without knowing the exact details of the job that made them.
We would like to be able to find artifacts by at least: #* Knowing the build URL in
Jenkins #* Knowing the STDCI stage/project/branch/distro/arch/git hash combination. #*
Asking for STDCI stage/project/branch/distro/arch/latest artifact We need to achieve the
above without significantly harming the UX we provide. For example, users should still be
able to find artifacts by navigating from links posted to Gerrit/GitHub to the Jenkins job
result pages.</p></blockquote>
<p>&mdash; This message was sent by Atlassian Jira
(v1001.0.0-SNAPSHOT#100070)</p>

------------=_1510041765-21211-504--

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

[JIRA] (OVIRT-1744) Revisit build artifact storage and retnesion