[JIRA] (OVIRT-1391) Add repo injection capabilities to STD-CI
by Barak Korren (oVirt JIRA)
[ https://ovirt-jira.atlassian.net/browse/OVIRT-1391?page=com.atlassian.jir... ]
Barak Korren updated OVIRT-1391:
--------------------------------
Epic Link: OVIRT-400
> Add repo injection capabilities to STD-CI
> -----------------------------------------
>
> Key: OVIRT-1391
> URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1391
> Project: oVirt - virtualization made easy
> Issue Type: New Feature
> Components: Jenkins
> Reporter: Barak Korren
> Assignee: infra
> Priority: High
>
> This is a part of [containers CI/CD|https://docs.google.com/a/redhat.com/document/d/1mEo3E0kRvlUWT9VaSP...] flow implementation process.
> We want to add to standard-CI ('{{mock-runner.sh}}') the capability to provide a project with information about package repositories that unrelated to the setup of the environment that standard-CI scripts run in.
> A projects will specify required repositories by including one or more files that match the pattern “{{automation/$STD_CI_STAGE.\*.yumrepos.\*}}”, where “{{$STG_CI_STAGE}}” is e.g “{{build-system-artifacts}}” and the wildcard sections can be omitted along with the dots that precede them. The file should be in the format of a yum configuration file and include configuration for required yum repositories. To avoid the projects having to maintain URLs for yum repositories, the file may contain configurations without repository URLs specified and with the “skip_if_unavailable” parameter set to “true”. Only the names of the repository configuration sections will be meaningful for the purpose of the CI system. For each such file the CI system will:
> # Replace any configuration section that defines the “{{ovirt-<distro-id>}}” repository with one or more configuration sections pointing to repositories from which oVirt packages for the distribution identified by "{{<distro-id>}}" may be obtained. “{{<distro-id>}}" will be a string such as “el7” or “fc25”. To allow avoiding collisions with the released oVirt yum configuration, the “{{ovirt-ci-<repoid>}}” and “{{ovirt-experimental-<repoid>}}” configuration section will be treated the same way.
> # Replace any configuration section that defines the “{{ovirt-dependencies-<distro-id>}}” repository with one or more configuration sections pointing to repositories from which oVirt dependency packages need to be obtained. These will include, among others, base operating system packages. The “{{ovirt-ci-dependencies-<repoid>}}” and “{{ovirt-experimental-dependencies-<repoid>}}” configuration section will be treated the same way.
> # Run the mirror injection process. Any repository handled by this process will have the the “{{skip_if_unavailable}}” parameter removed if specified (To make the default value of “{{false}}” come into effect).
> # Prepend a “{{\[main]}}” section that disables the use of the “{{/etc/yum.repos.d}}” directory. This will allow the file to appended to the "{{/etc/yun.conf}}” file to automatically disable all internet-facing preconfigured repositories.
> To allow automation scripts to find the repository files prepared for them, several environment variables will be made available in the Standard-CI runtime environment:
> # {{STD_CI_STAGE}}: Will contain the name of the Standard-CI stage, e.g. “{{build-artifacts}}”.
> # {{STD_CI_DISTRO}}: Will contain the distribution version identifier (e.g “el7” or “fc25”) of the Standard-CI runtime.
> # {{STD_CI_YUMREPOS}}: Will point to an existing “{{*.yumrepos}}” file that most closely matches the current running stage and distribution
--
This message was sent by Atlassian JIRA
(v1000.990.2#100044)
7 years, 6 months
[JIRA] (OVIRT-1390) Implement "archive-artifacts" flow for containers in STD-CI
by Barak Korren (oVirt JIRA)
[ https://ovirt-jira.atlassian.net/browse/OVIRT-1390?page=com.atlassian.jir... ]
Barak Korren reassigned OVIRT-1390:
-----------------------------------
Assignee: Daniel Belenky (was: infra)
> Implement "archive-artifacts" flow for containers in STD-CI
> -----------------------------------------------------------
>
> Key: OVIRT-1390
> URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1390
> Project: oVirt - virtualization made easy
> Issue Type: New Feature
> Components: Jenkins
> Reporter: Barak Korren
> Assignee: Daniel Belenky
> Priority: High
> Labels: standard-ci
>
> This is a part of [containers CI/CD|https://docs.google.com/a/redhat.com/document/d/1mEo3E0kRvlUWT9VaSP...] flow implementation process.
> We want to implement functionality similar to what "archive-artifacts" gives use for regular files, for containers in standard-CI.
> The design as as following:
> # An STD-CI script that generated container images need to tag them with the "exported-artifacts" tag.
> # After the STD-CI script finishes successfully, the CI system will take the tagged container images and push them the the "{{ovirtinfra}}" account on DockerHub.
> # The CI system will tage pushed images with the SHA1 hash of the URL of the Jenkins job build that built the image (Can be found in $BUILD_URL)
> # The CI system will output examples for '{{docker pull}}' and '{{docker run}}' command that would be needed to obtain the build image to the build status screen (Using the Groovy post-build plugin)
--
This message was sent by Atlassian JIRA
(v1000.990.2#100044)
7 years, 6 months
[JIRA] (OVIRT-1390) Implement "archive-artifacts" flow for containers in STD-CI
by Barak Korren (oVirt JIRA)
[ https://ovirt-jira.atlassian.net/browse/OVIRT-1390?page=com.atlassian.jir... ]
Barak Korren updated OVIRT-1390:
--------------------------------
Description:
This is a part of [containers CI/CD|https://docs.google.com/a/redhat.com/document/d/1mEo3E0kRvlUWT9VaSP...] flow implementation process.
We want to implement functionality similar to what "archive-artifacts" gives use for regular files, for containers in standard-CI.
The design as as following:
# An STD-CI script that generated container images need to tag them with the "exported-artifacts" tag.
# After the STD-CI script finishes successfully, the CI system will take the tagged container images and push them the the "{{ovirtinfra}}" account on DockerHub.
# The CI system will tage pushed images with the SHA1 hash of the URL of the Jenkins job build that built the image (Can be found in $BUILD_URL)
# The CI system will output examples for '{{docker pull}}' and '{{docker run}}' command that would be needed to obtain the build image to the build status screen (Using the Groovy post-build plugin)
was:
This is a part of [containers CI/CD|https://docs.google.com/a/redhat.com/document/d/1mEo3E0kRvlUWT9VaSP...] flow implementation process.
We want to implement functionality similar to what "archive-artifacts" gives use for regular files, for containers in standard-CI.
The design as as following:
# An STD-CI script that generated container images need to tag them with the "exported-artifacts" tag.
# After the STD-CI script finishes successfully, the CI system will take the tagged container images and push them the the "ovirtinfra" account on DockerHub.
# The CI system will tage pushed images with the SHA1 hash of the URL of the Jenkins job build that built the image (Can be found in $BUILD_URL)
# The CI system will output examples for '{{docker pull}}' and '{{docker run}}' command that would be needed to obtain the build image to the build status screen (Using the Groovy post-build plugin)
> Implement "archive-artifacts" flow for containers in STD-CI
> -----------------------------------------------------------
>
> Key: OVIRT-1390
> URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1390
> Project: oVirt - virtualization made easy
> Issue Type: New Feature
> Components: Jenkins
> Reporter: Barak Korren
> Assignee: infra
> Priority: High
> Labels: standard-ci
>
> This is a part of [containers CI/CD|https://docs.google.com/a/redhat.com/document/d/1mEo3E0kRvlUWT9VaSP...] flow implementation process.
> We want to implement functionality similar to what "archive-artifacts" gives use for regular files, for containers in standard-CI.
> The design as as following:
> # An STD-CI script that generated container images need to tag them with the "exported-artifacts" tag.
> # After the STD-CI script finishes successfully, the CI system will take the tagged container images and push them the the "{{ovirtinfra}}" account on DockerHub.
> # The CI system will tage pushed images with the SHA1 hash of the URL of the Jenkins job build that built the image (Can be found in $BUILD_URL)
> # The CI system will output examples for '{{docker pull}}' and '{{docker run}}' command that would be needed to obtain the build image to the build status screen (Using the Groovy post-build plugin)
--
This message was sent by Atlassian JIRA
(v1000.990.2#100044)
7 years, 6 months
[JIRA] (OVIRT-1390) Implement "archive-artifacts" flow for containers in STD-CI
by Barak Korren (oVirt JIRA)
[ https://ovirt-jira.atlassian.net/browse/OVIRT-1390?page=com.atlassian.jir... ]
Barak Korren updated OVIRT-1390:
--------------------------------
Description:
This is a part of [containers CI/CD|https://docs.google.com/a/redhat.com/document/d/1mEo3E0kRvlUWT9VaSP...] flow implementation process.
We want to implement functionality similar to what "archive-artifacts" gives use for regular files, for containers in standard-CI.
The design as as following:
# An STD-CI script that generated container images need to tag them with the "exported-artifacts" tag.
# After the STD-CI script finishes successfully, the CI system will take the tagged container images and push them the the "ovirtinfra" account on DockerHub.
# The CI system will tage pushed images with the SHA1 hash of the URL of the Jenkins job build that built the image (Can be found in $BUILD_URL)
# The CI system will output examples for '{{docker pull}}' and '{{docker run}}' command that would be needed to obtain the build image to the build status screen (Using the Groovy post-build plugin)
was:
This is a part of [containers CI/CD|https://docs.google.com/a/redhat.com/document/d/1mEo3E0kRvlUWT9VaSP...] flow implementation process.
We want to implement functionality similar to what "archive-artifacts" gives use for regular files, for containers in standard-CI.
The design as as following:
# An STD-CI script that generated container images need to tag them with the "exported-artifacts" tag.
# After the STD-CI script finishes successfully, the CI system will take the tagged container images and push them the the "ovirtci" account on DockerHub.
# The CI system will tage pushed images with the SHA1 hash of the URL of the Jenkins job build that built the image (Can be found in $BUILD_URL)
# The CI system will output examples for '{{docker pull}}' and '{{docker run}}' command that would be needed to obtain the build image to the build status screen (Using the Groovy post-build plugin)
> Implement "archive-artifacts" flow for containers in STD-CI
> -----------------------------------------------------------
>
> Key: OVIRT-1390
> URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1390
> Project: oVirt - virtualization made easy
> Issue Type: New Feature
> Components: Jenkins
> Reporter: Barak Korren
> Assignee: infra
> Priority: High
> Labels: standard-ci
>
> This is a part of [containers CI/CD|https://docs.google.com/a/redhat.com/document/d/1mEo3E0kRvlUWT9VaSP...] flow implementation process.
> We want to implement functionality similar to what "archive-artifacts" gives use for regular files, for containers in standard-CI.
> The design as as following:
> # An STD-CI script that generated container images need to tag them with the "exported-artifacts" tag.
> # After the STD-CI script finishes successfully, the CI system will take the tagged container images and push them the the "ovirtinfra" account on DockerHub.
> # The CI system will tage pushed images with the SHA1 hash of the URL of the Jenkins job build that built the image (Can be found in $BUILD_URL)
> # The CI system will output examples for '{{docker pull}}' and '{{docker run}}' command that would be needed to obtain the build image to the build status screen (Using the Groovy post-build plugin)
--
This message was sent by Atlassian JIRA
(v1000.990.2#100044)
7 years, 6 months
[JIRA] (OVIRT-1376) Make mock_runner.sh easier to use locally
by Barak Korren (oVirt JIRA)
[ https://ovirt-jira.atlassian.net/browse/OVIRT-1376?page=com.atlassian.jir... ]
Barak Korren updated OVIRT-1376:
--------------------------------
Summary: Make mock_runner.sh easier to use locally (was: Make mock_runner.sh easer to use locally)
> Make mock_runner.sh easier to use locally
> -----------------------------------------
>
> Key: OVIRT-1376
> URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1376
> Project: oVirt - virtualization made easy
> Issue Type: New Feature
> Components: Jenkins
> Reporter: Barak Korren
> Assignee: infra
> Priority: Low
>
> Currently to use '{{mock_runner.sh}}', one needs to:
> # Install '{{mock}}' (Might require adding some '{{yum}}' repos, also reuquires one to be running RHEL, CentOS or Fedora in the 1st place)
> # Add one`s user account to the '{{mock}}' group (requires logoff and logon)
> # Clone the '{{jenkins}}' repo
> # Use a long set of command line arguments to make '{{mock_runner.sh}}' use the right '{{mock}}' configuration files
> All this is making '{{mock_runner.sh}}' hard and unpopular for local use. Also, no knowing one need to do the above leads to strange errors. We can improve this by:
> # Making '{{mock_runner.sh}' check that everything is configured correctly and output meaningful warnings otherwise
> # Setup the default so that '{{mock_runner.sh}}' knows how the find the right configuration files
> # Package '{{mock_runner.sh}}' in one way or another so that one doesn't need to clone a whole repo to install it.
> When it comes to packaging we have several options to consider:
> * Using an RPM package:
> ** Pros:
> *** Familiar format
> *** Can include '{{mock}}' as a dependency.
> ** Cons:
> *** One has to use CentOS or Fedora
> *** One most have '{{root}}' permissions to install packages
> * Using a self-contained executable built with a tool like [pyinstaller|https://pyinstaller.readthedocs.io/en/stable/operating-mode.html].
> ** Pros:
> *** Installation is just downloading a single file to a directory in '{{$PATH}}'
> ** Cons:
> *** One will probably need to install '{{mock}}' and other dependencies manually.
> *** '{{pyinstaller}}' is mostly for Python projects, while '{{mock_runner.sh}}' is a shell script.
> * Using a Docker container:
> ** Pros:
> *** Everything can be pre-configured in the container, including '{{mock}}' itself and all needed permissions
> *** Can run on any platform that can run Docker
> ** Cons:
> *** One needs Docker itself to be installed and configured
> *** '{{mock}}' may not run well inside a container
> *** Everything that is mounted into the mock environment must first be mounted into the container. This will probably require the container to run in privileged mode. This also means that running the container with the right mounts may be a complicated matter.
> *** The container image may end up being quite big.
--
This message was sent by Atlassian JIRA
(v1000.990.2#100044)
7 years, 6 months
[JIRA] (OVIRT-1390) Implement "archive-artifacts" flow for containers in STD-CI
by Barak Korren (oVirt JIRA)
Barak Korren created OVIRT-1390:
-----------------------------------
Summary: Implement "archive-artifacts" flow for containers in STD-CI
Key: OVIRT-1390
URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1390
Project: oVirt - virtualization made easy
Issue Type: New Feature
Components: Jenkins
Reporter: Barak Korren
Assignee: infra
Priority: High
This is a part of [containers CI/CD|https://docs.google.com/a/redhat.com/document/d/1mEo3E0kRvlUWT9VaSP...] flow implementation process.
We want to implement functionality similar to what "archive-artifacts" gives use for regular files, for containers in standard-CI.
The design as as following:
# An STD-CI script that generated container images need to tag them with the "exported-artifacts" tag.
# After the STD-CI script finishes successfully, the CI system will take the tagged container images and push them the the "ovirtci" account on DockerHub.
# The CI system will tage pushed images with the SHA1 hash of the URL of the Jenkins job build that built the image (Can be found in $BUILD_URL)
# The CI system will output examples for '{{docker pull}}' and '{{docker run}}' command that would be needed to obtain the build image to the build status screen (Using the Groovy post-build plugin)
--
This message was sent by Atlassian JIRA
(v1000.990.2#100044)
7 years, 6 months
[JIRA] (OVIRT-1390) Implement "archive-artifacts" flow for containers in STD-CI
by Barak Korren (oVirt JIRA)
[ https://ovirt-jira.atlassian.net/browse/OVIRT-1390?page=com.atlassian.jir... ]
Barak Korren updated OVIRT-1390:
--------------------------------
Epic Link: OVIRT-400
> Implement "archive-artifacts" flow for containers in STD-CI
> -----------------------------------------------------------
>
> Key: OVIRT-1390
> URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1390
> Project: oVirt - virtualization made easy
> Issue Type: New Feature
> Components: Jenkins
> Reporter: Barak Korren
> Assignee: infra
> Priority: High
> Labels: standard-ci
>
> This is a part of [containers CI/CD|https://docs.google.com/a/redhat.com/document/d/1mEo3E0kRvlUWT9VaSP...] flow implementation process.
> We want to implement functionality similar to what "archive-artifacts" gives use for regular files, for containers in standard-CI.
> The design as as following:
> # An STD-CI script that generated container images need to tag them with the "exported-artifacts" tag.
> # After the STD-CI script finishes successfully, the CI system will take the tagged container images and push them the the "ovirtci" account on DockerHub.
> # The CI system will tage pushed images with the SHA1 hash of the URL of the Jenkins job build that built the image (Can be found in $BUILD_URL)
> # The CI system will output examples for '{{docker pull}}' and '{{docker run}}' command that would be needed to obtain the build image to the build status screen (Using the Groovy post-build plugin)
--
This message was sent by Atlassian JIRA
(v1000.990.2#100044)
7 years, 6 months
Update contact info on the website
by Marc Dequènes (Duck)
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--sXwOabLOqc1oQie2ANAwv0LIvC3aXQkil
Content-Type: multipart/mixed; boundary="rGJ8DtXqluq7aaqlvb1QEkC3OtgTMvtMq";
protected-headers="v1"
From: =?UTF-8?B?TWFyYyBEZXF1w6huZXMgKER1Y2sp?= <duck(a)redhat.com>
To: oVirt Infra <infra(a)ovirt.org>
Message-ID: <ad367d9e-3ffa-24da-577d-fce85b08f0c2(a)redhat.com>
Subject: Update contact info on the website
--rGJ8DtXqluq7aaqlvb1QEkC3OtgTMvtMq
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Quack,
We should really cleanup this page:
http://www.ovirt.org/develop/infra/infrastructure/
David Caro left the project, Evegheny and me are missing, and I'm sure
the role descriptions do not match reality anymore for some of you.
I can do the editorial work if you give me all the changes you wish to
see on this thread.
\_o<
--rGJ8DtXqluq7aaqlvb1QEkC3OtgTMvtMq--
--sXwOabLOqc1oQie2ANAwv0LIvC3aXQkil
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEEcpcqg+UmRT3yiF+BVen596wcRD8FAlkd0iMACgkQVen596wc
RD/H1hAAuXn6tIKBPaGv5xFD/tJP7aIXJsy8tUlx0YsgxFjp+GsS109Lj8HwY1HE
H5gPwYRTjL/BaHhOowRtH3u7aRPfus1cP7qi9sd+x7+Fxdw74ATiun+limbj24E8
mLyvvy2OrWdEelY54hP419iJe+thkFLams1eAB3tGySCX+T8ZUpHGCvtpJ8dkxfX
OcYaM8iVNO0NMH9pjorhFFv8Ghkb4wWwlC+dPQBVpVzXzgnbX/1LpjXSHVb5P8CF
ifz1D5xHafJT/7ic9ND1lLRlxympFzGCOOzY5Uw0cV+bPASUOHNsnsRK02kSLCFp
vR4RSzG/+ZmandaBZEDCmoJY+wr3JY2JLc5ffaRJa2cvTdm92gRPOqju6MU0qOgA
ecuI3JL8tBSiBaXXXU92+tqrr4l1yp9qaN/1vGLh2qA/2iF2hLSq/t6vzqIKYgCO
r7h0z5IF7WuwHTQqt/azO6/sgDfMMpk69ozgzFOgAfDZnGCp2/dJ83TYaaihgQvx
2vtFedOWEIcW2TkUoTa9CeHLn7qu9kOhVj56FNwYJsRPiSxRq7arq0F/kJazZzYd
exslNIqzMgYK7nHFvc6EloBSPubY9NxMpnYmiR3ewBrbcABeT18ZWVvLfnceJc/O
QYAnim5+R30HcugAE1Cwmkv9sLgDfteUQCHFF3M5ZksgI4+4A9Q=
=Q99X
-----END PGP SIGNATURE-----
--sXwOabLOqc1oQie2ANAwv0LIvC3aXQkil--
7 years, 6 months
