-
Notifications
You must be signed in to change notification settings - Fork 143
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
Request access to previously pushed release via balena deploy
#1057
Conversation
lib/utils/compose.coffee
Outdated
repos = [] | ||
for i in images | ||
imageName = i.image[0].is_stored_at__image_location | ||
[ _, _, repoName, _ = 'latest' ] = /(.*?)\/(.*?)(?::([^/]*))?$/.exec(imageName) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Might be better to use a tighter regex, as in https://github.com/balena-io-modules/docker-toolbelt/blob/master/lib/docker-toolbelt.coffee#L338 (you could even use that docker-toolbelt module)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Admittedly I stole this regex from https://github.com/balena-io/balena-cli/blob/master/lib/utils/compose.coffee#L338, but I think making use of docker-toolbelt sounds like a much better long-term plan. Will update that, thank you!
I've restructured this PR to use |
I believe the build failures in travis are related to #1059 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am requesting some changes but don't assume that my requests are particularly wise! :-)
lib/utils/compose.coffee
Outdated
|
||
.then (release) -> | ||
# grab all images from the latest release, return all image locations in the registry | ||
if release.length > 0 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've probably never called sdk.pine.get() so feel free to ignore this question -- save time and don't even bother answering if you think you know what you are doing. Otherwise, could release
be null or undefined? In which case release.length
would be a ReferenceError
, and the safer Coffeescript expression might be release?.length > 0
which would evaluate to false.
I am still sorting the case where pushing more than 10 images as part of a docker-compose causes the json to be truncated. |
At Alex's behest I added some hacky workaround to deal with #1070, otherwise this PR is ready to merge if it looks good! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@xginn8, thanks for the changes, it's looking good! Just some tidying up before merging:
- There are 9 commits and they are not all individually relevant as checkout points for future contributors to the git repo, so I recommend squashing them. There's a sentence about this in the Commit and PR Guidelines process document -- search it for the word 'squash'. (Typically this becomes relevant in future investigations that try to identify a commit that introduced some change or broke something, and for most PRs I believe this should be a single commit.) I'd squash all of the PR's commits into a single one. There are multiple ways to achieve squashing. I normally use
git log
to find the commit hash of the commit that precedes all the commits in the PR, then rungit rebase -i <that_commit_hash>
, then in the editor I select squash for all commits except the first, then edit the commit message. Btw, maybe I'm missing out on a simpler way of doing it... - I see that 2 of the 9 commits are merge commits. We prefer rebasing as it leads to a cleaner linear history. (Conceptually I also find rebasing more intuitive: we want to apply our changes to the origin repository, rather than apply the origin repository to our changes. Rebase should have been the default action taken by
git pull
when git was designed...) There are multiple ways to achieve rebasing. The command I like best isgit pull --rebase origin master
, as it combines severals steps into one. The Commit and PR Guidelines process document describes how to do it using 4 separate commands / steps. - So after squashing the commits, please rebase on master.
- The PR title spilled into the message box: when pushing via `balena…
... deploy`. I don't really remember how this affects the automatic changes to the CHANGELOG by versionbot, but better edit the title to fit in a single line. Maybe it's just the commit messages that get copied to the CHANGELOG, not the PR title? In any case, please review the PR and commit messages so that they are most useful to customers / contributors who will be reading the CHANGELOG and browsing the PR history.
a830ac9
to
e5b6a7b
Compare
balena deploy
This access is used to cross mount the old layers, rather than reuploading the layers each time. Connects-to: #1045 Change-type: minor Signed-off-by: Matthew McGinn <[email protected]>
06bb4d8
to
a42a1a9
Compare
Rebased all the iterations into one commit, @pdcastro PTAL |
This access is used to cross mount the old layers, rather than
reuploading the layers each time.
Connects-to: #1045
Change-type: minor
Signed-off-by: Matthew McGinn [email protected]