Based on appveyor/ci#1865 [skip appveyor] You can view, comment on, or merge this pull request online at:https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/349 Commit Summary
File Changes
Patch Links:
— |
@akgrant43 pushed 1 commit.
— |
In reply to this post by David T Lewis
Hi @akgrant43, — |
In reply to this post by David T Lewis
Hi Fabio, My understanding with the default commit filter is that it requires the [skip ci] message in the commit title. Most people don't want the first line of the commit polluted by this type of message, so the idea here is to allow the [skip ci] to be placed anywhere in the commit message (it has it's own drawbacks, see https://help.appveyor.com/discussions/problems/11603-skip-ci-doesnt-work-as-expected for a discussion (thanks to Ben for providing this link). Cheers, — |
In reply to this post by David T Lewis
@akgrant43 pushed 1 commit.
— |
In reply to this post by David T Lewis
@akgrant43 pushed 1 commit.
— |
In reply to this post by David T Lewis
Interesting... We could be using something like this
— |
In reply to this post by David T Lewis
Hi Nicolas,
The drawback of this approach is that we identify the VM by the commit id, and this will prevent the same commit id being present on all platforms whenever a change is made that doesn't affect Windows. — |
In reply to this post by David T Lewis
Well shouldn't it work that way? I mean, there are other drawbacks of identifying VMs by commit id (e.g. the need for git hooks). More importantly, why rebuild all Linux/macOS VMs when only Windows code was modified? I have never expected bleeding edge "releases" on Bintray to be complete, no one really should because they are mainly for development and builds happen to fail from time to time. Stable release builds will still be triggered simultaneously on AppVeyor and Travis. So we should be fine, right? — |
In reply to this post by David T Lewis
I'm not sure. If we introduced a version number or build number there may still be a need to substitute it in to other files, so there may still be a use for the commit hooks. And event with the other identifier, I wouldn't want to get rid of the CommitHash - it makes it easy as a developer to find the code.
This is a good point, of course.
Implicit in what you're saying is that someone then manually starts a full build for every release candidate. So, I'm fine with the change you're proposing, it just requires buy-in from the people that are actually responsible for the releases in the various flavours (and thus are responsible for ensuring a full build for the released VM). It also doesn't completely remove the usefulness of being able to skip building when desired. :-) — |
In reply to this post by David T Lewis
Merged #349 into Cog. — |
Free forum by Nabble | Edit this page |