-
Notifications
You must be signed in to change notification settings - Fork 105
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
error bumping version: private keys with passphrases are not supported #115
Comments
I found the problem... but it may be something nice to address in the resource. It was indeed a key finishing without the new blank line. The bad news is that we use AWS secret manager and it seems to strip blank lines no matter what... Adding any arbitrary new line would make it work but it is not a scalable solution, and other concourse resources seem to tolerate this, so at a very least there's an inconsistent approach that would be nice to address. |
For anyone interested, a cleaner workaround in case you cannot add a blank line to the key (that was our case) would be: - name: version
type: semver
source:
initial_version: "0.0.0"
driver: git
uri: [email protected]:org/versions.git
private_key: |
((versions-deploy-key))
branch: master
file: a-service |
Yep ! Works ! Thank you very much :) |
This issue was identified here: #79 What I find interesting is that sombody proposed a possible code change for a PR. 🤔 |
See more details in: concourse/semver-resource#115
…t of the semver resource see concourse/semver-resource#115 Co-authored-by: Georgi Sabev <[email protected]>
I have a pair of credentials that are not passphrase protected. The key has read/write access in GitHub.
For the current pipeline:
and the following resources:
I get the error:
error bumping version: private keys with passphrases are not supported
I saw a similar report in the git resource and followed advice there... The interesting thing is that if I use the version repo as input for the git resource, the git resource is capable of fetching the latest version commit (and then the version resource complains even though it is using the very same key/url), which proves:
Any thoughts?
The text was updated successfully, but these errors were encountered: