Do the CI support creating a github releases + assets?
I'm currently rolling my own makefile to create a release, with a binary file as assets. Does standard CI have something to publish artifacts in GH releases?
On 13 February 2018 at 11:59, Roy Golan <rgolan@redhat.com> wrote:
I'm currently rolling my own makefile to create a release, with a binary file as assets. Does standard CI have something to publish artifacts in GH releases?
We don't have built-in support for it (And probably never will, because we believe in releasing oVirt stuff on ovirt.org resources), but we have credentials support so you can give us credentials for using the GitHub API to access it on your behalf, and then have those credentials made available to build scripts. Also, a plain binary is a bad choice for a release mechanism IMO, it does not contain any useful metadata. Release media should typically at least include enough metadata to let you know which release is newer then another... Why not wrap it in an RPM or a container? -- Barak Korren RHV DevOps team , RHCE, RHCi Red Hat EMEA redhat.com | TRIED. TESTED. TRUSTED. | redhat.com/trusted
On 13 February 2018 at 11:59, Roy Golan <rgolan@redhat.com> wrote:
I'm currently rolling my own makefile to create a release, with a binary file as assets. Does standard CI have something to publish artifacts in GH releases?
We don't have built-in support for it (And probably never will, because we believe in releasing oVirt stuff on ovirt.org resources), but we have credentials support so you can give us credentials for using the GitHub API to access it on your behalf, and then have those credentials made available to build scripts.
Yes I imagined this is what we have. I guess This is what I'll do for releases, build the rpm and push a release with a link to the repo. I'll need more details when I'll
On Wed, 14 Feb 2018 at 09:19 Barak Korren <bkorren@redhat.com> wrote: there, like the official rpm repo link and so on. Also, a plain binary is a bad choice for a release mechanism IMO, it
does not contain any useful metadata. Release media should typically at least include enough metadata to let you know which release is newer then another...
Why not wrap it in an RPM or a container?
I know merged the RPM support. :)
I'm haing problem with running glide in mock locally. It is stuck on downloading k8s.io/kubernetes - Did anyone you see that before? anyone building go in mock?
-- Barak Korren RHV DevOps team , RHCE, RHCi Red Hat EMEA redhat.com | TRIED. TESTED. TRUSTED. | redhat.com/trusted
On 14 February 2018 at 13:40, Roy Golan <rgolan@redhat.com> wrote:
On Wed, 14 Feb 2018 at 09:19 Barak Korren <bkorren@redhat.com> wrote:
On 13 February 2018 at 11:59, Roy Golan <rgolan@redhat.com> wrote:
I'm currently rolling my own makefile to create a release, with a binary file as assets. Does standard CI have something to publish artifacts in GH releases?
We don't have built-in support for it (And probably never will, because we believe in releasing oVirt stuff on ovirt.org resources), but we have credentials support so you can give us credentials for using the GitHub API to access it on your behalf, and then have those credentials made available to build scripts.
Yes I imagined this is what we have. I guess This is what I'll do for releases, build the rpm and push a release with a link to the repo. I'll need more details when I'll there, like the official rpm repo link and so on.
Also, a plain binary is a bad choice for a release mechanism IMO, it does not contain any useful metadata. Release media should typically at least include enough metadata to let you know which release is newer then another...
Why not wrap it in an RPM or a container?
I know merged the RPM support. :)
I'm haing problem with running glide in mock locally. It is stuck on downloading k8s.io/kubernetes - Did anyone you see that before? anyone building go in mock?
Kubevirt is doing that ATM. In you have network access issues - make sure you're using a recent enough version of mock_runner.sh. Recent versions of mock turn off networking and you need an updated mock_runner.sh that knows how to turn it back on. -- Barak Korren RHV DevOps team , RHCE, RHCi Red Hat EMEA redhat.com | TRIED. TESTED. TRUSTED. | redhat.com/trusted
participants (2)
-
Barak Korren -
Roy Golan