Open Stack

On 07/30/2018 02:04 PM, Sean McGinnis wrote:
> On Mon, Jul 30, 2018 at 12:02:50PM -0500, Ben Nemec wrote:
>> According to https://bugs.launchpad.net/pbr/+bug/1742809 our github release
>> tarballs don't actually work.  It seems to be a github-specific issue
>> because I was unable to reproduce the problem with a tarball from
>> releases.openstack.org.
>>
>> My best guess is that github's release process differs from ours and doesn't
>> work with our projects.  I see a couple of options for fixing that.  Either
>> we figure out how to make Github's release process DTRT for our projects, or
>> we figure out a way to override Github's release artifacts with our own.
>> I'm not familiar enough with this to know which is a better (or even
>> possible) option, so I'm sending this to solicit help.
>>
>> Thanks.
>>
>> -Ben
>>
> 
>  From what I understand, GitHub will provide zip and tar.gz links for all source
> whenever a tag is applied. It is a very basic operation and does not have any
> kind of logic for correctly packaging whatever that deliverable is.
> 
> They even just label the links as "Source code".
> 
> I am not sure if there is any way to disable this behavior. One option I see is
> we could link in the tag notes to the official tarballs.openstack.org location.
> We could also potentially look at using the GitHub API to upload a copy of
> those to the GitHub release page. But there's always a mirroring delay, and
> GitHub really is just a mirror of our git repos, so using this as a
> distribution point really isn't what we want.

Yeah, I talked a bit more about this with Monty on IRC, and it turns out 
there is already an RFE for Github to hide releases that were 
auto-generated from tags: 
https://github.community/t5/How-to-use-Git-and-GitHub/Tag-without-release/m-p/7906

Apparently from the github side "releases" already aren't created unless 
the project does so explicitly, but they show all tags on the release 
tab anyway so the user-visible difference is pretty much nil.  We 
decided to table this until we find out if Github is going to fix it for 
us.  It doesn't make sense to do a bunch of work and then turn around 
and not need it because Github rationalized their UI while we were 
trying to work around it.