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.

Sign up for GitHub

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

Jump to bottom

Scopes for token #3

Closed
eddiemonge opened this issue Jul 22, 2015 · 1 comment · Fixed by #47
Closed

Scopes for token #3

eddiemonge opened this issue Jul 22, 2015 · 1 comment · Fixed by #47

Comments

@eddiemonge
Copy link

What scopes are needed for the token? this should be included in the docs probably.
@stevemao
Copy link
Member

Ref: https://developer.github.com/v3/oauth/#scopes

@hutson hutson added the support label May 30, 2017
hutson added a commit that referenced this issue Jun 25, 2017
@hutson
fix(index): handle error when posting new tags
7c1e4d9 
Previous behavior was based on the use of `Q.allSettled`, which does not
distinguish between a successful promise, or a rejected promise.
Therefore, even if `conventional-gitlab-releaser` failed to post a new
GitLab Release page, `conventional-gitlab-releaser` would still call the
callback without an error, thereby causing consumers to assume
everything succeeded.

New behavior is based on the use of `Q.all`, which will distinguish
between a fulfilled promise and a rejected promise. Therefore we can
register a `then` callback for success, and a `catch` callback to handle
the first promise that fails.

Concern: Because we make POST requests for new tags concurrently, some
tags, and their respective Release pages, may be successfully created on
GitLab, yet `conventional-gitlab-releaser` could still report failure if
even a single POST request fails. That could leave the process of
creating tags in an undesired state. Long-term, perhaps we should
cleanup all created tags if a single request fails so that we leave the
target project in a clean state. (Though we need to also consider that
tag creation may automatically trigger other downstream processes; such
as CI).

Fixes #3
@danez danez mentioned this issue Sep 1, 2017
Merged
hutson pushed a commit that referenced this issue Mar 19, 2018
@stevemao @hutson
docs(token): what scopes are needed for the token
0965b34 
Closes #3
hutson added a commit that referenced this issue Mar 19, 2018
@hutson
fix(index): handle error when posting new tags
95bd719 
Previous behavior was based on the use of `Q.allSettled`, which does not
distinguish between a successful promise, or a rejected promise.
Therefore, even if `conventional-gitlab-releaser` failed to post a new
GitLab Release page, `conventional-gitlab-releaser` would still call the
callback without an error, thereby causing consumers to assume
everything succeeded.

New behavior is based on the use of `Q.all`, which will distinguish
between a fulfilled promise and a rejected promise. Therefore we can
register a `then` callback for success, and a `catch` callback to handle
the first promise that fails.

Concern: Because we make POST requests for new tags concurrently, some
tags, and their respective Release pages, may be successfully created on
GitLab, yet `conventional-gitlab-releaser` could still report failure if
even a single POST request fails. That could leave the process of
creating tags in an undesired state. Long-term, perhaps we should
cleanup all created tags if a single request fails so that we leave the
target project in a clean state. (Though we need to also consider that
tag creation may automatically trigger other downstream processes; such
as CI).

Fixes #3
hutson pushed a commit that referenced this issue Mar 19, 2018
@stevemao @hutson
docs(token): what scopes are needed for the token
ec9eef5 
Closes #3
hutson added a commit that referenced this issue Mar 19, 2018
@hutson
fix(index): handle error when posting new tags
72a5782 
Previous behavior was based on the use of `Q.allSettled`, which does not
distinguish between a successful promise, or a rejected promise.
Therefore, even if `conventional-gitlab-releaser` failed to post a new
GitLab Release page, `conventional-gitlab-releaser` would still call the
callback without an error, thereby causing consumers to assume
everything succeeded.

New behavior is based on the use of `Q.all`, which will distinguish
between a fulfilled promise and a rejected promise. Therefore we can
register a `then` callback for success, and a `catch` callback to handle
the first promise that fails.

Concern: Because we make POST requests for new tags concurrently, some
tags, and their respective Release pages, may be successfully created on
GitLab, yet `conventional-gitlab-releaser` could still report failure if
even a single POST request fails. That could leave the process of
creating tags in an undesired state. Long-term, perhaps we should
cleanup all created tags if a single request fails so that we leave the
target project in a clean state. (Though we need to also consider that
tag creation may automatically trigger other downstream processes; such
as CI).

Fixes #3
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

fix(cli): Remove broken error handling
3 participants
@eddiemonge @stevemao @hutson