Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

x/build/cmd/release: create GitHub releases #15966

Open
adg opened this issue Jun 6, 2016 · 8 comments
Open

x/build/cmd/release: create GitHub releases #15966

adg opened this issue Jun 6, 2016 · 8 comments
Assignees
Milestone

Comments

@adg
Copy link
Contributor

@adg adg commented Jun 6, 2016

GitHub has a "releases" feature that provides downloadable releases in a well-known location. We could make Go releases available via GitHub as well as our download page.

Assuming we want to do so, we could modify the release tool to create and populate those releases for us automatically.

But do we want to do this? What are the advantages? What are the disadvantages?

@adg adg added the NeedsDecision label Jun 6, 2016
@adg adg added this to the Unplanned milestone Jun 6, 2016
@broady
Copy link
Member

@broady broady commented Jun 6, 2016

I think I'd rather have a release API hosted on golang.org that provides a list of releases, tag names, binary URLs, etc.

@daaku
Copy link

@daaku daaku commented Jun 6, 2016

One advantage would be to provide an API via Github for tools like godeb to consume.

@ibnesayeed
Copy link

@ibnesayeed ibnesayeed commented Jul 6, 2016

I would vote for utilizing GitHub's releases feature. In fact it is already being utilized but only the source files are released. The only overhead I can think of is the added step in the release process, which is not an issue since it will be automated using GitHub's Releases API. A few advantages that I can think of are following:

  • Familiarity for GitHub users who might expect binaries in releases tab in line with other projects on GitHub that distribute binaries.
  • Automatic support in existing tools and workflows that utilize GitHub's Releases API.
  • Better metrics for researchers who analyze data from GitHub repositories.
  • Some corporate firewalls might block golang.org, for them GitHub might serve as an alternative mirror.
  • Service downtime is not uncommon, it can happen to any host, having an alternate is always helpful.
  • Lots Of Copies Keep Stuff Safe.

Note: To sanitize automatic source releases on GitHub, .gitattributes file needs some changes that are discussed in CR-24741. If desired, I can send a fresh change to take care of the source release sanitation.

@ghost
Copy link

@ghost ghost commented Jul 17, 2016

@broady why not both?

@bradfitz
Copy link
Contributor

@bradfitz bradfitz commented Mar 21, 2017

@broady, want to make a decision?

@gopherbot gopherbot added the Builders label Mar 21, 2017
@broady
Copy link
Member

@broady broady commented Mar 21, 2017

The only downside I can think of is that it makes it a little more difficult for analytics on downloads.
That said, we don't currently track downloads from golang.org/dl anyway, so it's not a huge downside.

I'll add this to the release tool. I don't see a pressing need for a separate API on golang.org.

The only thing to consider is whether to use @gopherbot's credentials or the end-user's GitHub credentials. I'd lean toward @gopherbot, and have gopherbot's token available from some endpoint gated by the "user-release" build token.

@codebien
Copy link

@codebien codebien commented Jun 22, 2019

I'm looking into this, if you accept a PR I would submit it.
I think this is helpful because it enables to support the Github's notification type "Notify on Releases only" and also if you haven't yet implemented any type of analytics, you can get a basic downloads counter.

However, I would before define the expected behavior for the command.

  1. When the process should be invoked? Is it an exclusive operation or can it be executed during other processes like the current upload?
  2. Create the release and upload the artifacts on Github can be in the same unique operation or would you split them?
  3. Here you can find the fields required by the Github endpoint, what are the values do you expect to see there? I’m thinking something similar to:

    • name: the go version released (e.g go1.12/go1.12.6)

    • body: a short description with links to the Downloads and Release notes pages.
    • artifacts: just the versions available in Featured downloads on dl.
  4. @broady Can we use the Gopherbot's credentials?
@codebien
Copy link

@codebien codebien commented Aug 28, 2019

@andybons Do you have any suggestion?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
7 participants
You can’t perform that action at this time.