You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Note: the term master branch is avoided on purpose. Many projects use another branch as primary branch, e.g., AppImageKit uses appimagetool/master, AppImageUpdate uses rewrite at the moment.
In many projects, there's development ongoing in branches outside the primary branch. Not everyone is happy with n forks for n developers, and for e.g., your own projects, GitHub creates branches in the same repository during many operations like file editing.
In such scenarios, uploadtool should not upload binaries to GitHub releases when Travis builds those branches. Instead, it should follow the PR strategy, and upload the binaries to https://transfer.sh (or some other location, see #28).
My current workaround in many projects is a line in the .travis.yml:
Note: the term
master
branch is avoided on purpose. Many projects use another branch as primary branch, e.g., AppImageKit usesappimagetool/master
, AppImageUpdate usesrewrite
at the moment.In many projects, there's development ongoing in branches outside the primary branch. Not everyone is happy with
n
forks forn
developers, and for e.g., your own projects, GitHub creates branches in the same repository during many operations like file editing.In such scenarios, uploadtool should not upload binaries to GitHub releases when Travis builds those branches. Instead, it should follow the PR strategy, and upload the binaries to https://transfer.sh (or some other location, see #28).
My current workaround in many projects is a line in the
.travis.yml
:https://github.com/AppImage/AppImageUpdate/blob/65b152ef3c5737aa7bea24ccd350556482a5656d/.travis.yml#L17
The text was updated successfully, but these errors were encountered: