GitHub now uses it's own key to sign commits when using the web interface - notably when using "Squash and Merge". This creates GPG signed commits into master which seemingly aren't handled by Clusterware. This is new (and seemingly unannounced) behaviour from GitHub - yay!
This can currently be seen by running alces gridware update with the volatile repository enabled. Updating volatile repo on (most?) Clusterware versions causes messages such as:
/opt/clusterware/lib/ruby/vendor/ruby/2.2.0/gems/grit-2.5.0/lib/grit/git-ruby/git_object.rb:254:in `block in from_raw' : unknown header 'gpgsig' in commit 9f9100a5e72132dcb6860d100d6cd8ea603d1951 (StandardWarning)
/opt/clusterware/lib/ruby/vendor/ruby/2.2.0/gems/grit-2.5.0/lib/grit/git-ruby/git_object.rb:254:in `block in from_raw' : unknown header '' in commit 9f9100a5e72132dcb6860d100d6cd8ea603d1951 (StandardWarning)
/opt/clusterware/lib/ruby/vendor/ruby/2.2.0/gems/grit-2.5.0/lib/grit/git-ruby/git_object.rb:254:in `block in from_raw' : unknown header '' in commit 9f9100a5e72132dcb6860d100d6cd8ea603d1951 (StandardWarning)
GitHub now uses it's own key to sign commits when using the web interface - notably when using "Squash and Merge". This creates GPG signed commits into
master
which seemingly aren't handled by Clusterware. This is new (and seemingly unannounced) behaviour from GitHub - yay!This can currently be seen by running
alces gridware update
with thevolatile
repository enabled. Updatingvolatile
repo on (most?) Clusterware versions causes messages such as: