Skip to content

Writable deploy keys (closes #671) #3225

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

Merged
merged 16 commits into from
Jan 6, 2018

Conversation

vtemian
Copy link
Contributor

@vtemian vtemian commented Dec 18, 2017

Add support for read/write deploy key (as github has).

It introduces a new option for write access and an info note that will show the user key's access mode (read/write).
Those options are supported by the API as well.
deploys
add-ssh

@lafriks lafriks added the type/feature Completely new functionality. Can only be merged if feature freeze is not active. label Dec 18, 2017
@lafriks lafriks added this to the 1.4.0 milestone Dec 18, 2017
@@ -600,6 +600,9 @@ type DeployKey struct {
Fingerprint string
Content string `xorm:"-"`

Mode AccessMode
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is access mode needed, why not just use ReadOnly?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also as table is changed it needs migration to Sync2 that type

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's a little tricky...

DeployKey seems to be just a proxy table, with some cached property (like Name and Fingerprint) of PublicKey. Using the same reasoning, I thought that it will be better to have a Mode column (like Name and Fingerprint).

Another way to do this will be to have retrieved the Mode from PublicKey (similar to how Content is retrieved), but this means an extra query for each access (most probably in AfterLoad function, since xorm doesn't that for you...maybe go-xorm/xorm#41 will solve it).

ReadOnly is just a property so I don't have to compare Mode with AccessRead, more like HasRecentActivity.

@@ -31,7 +31,7 @@
{{.Fingerprint}}
</div>
<div class="activity meta">
<i>{{$.i18n.Tr "settings.add_on"}} <span>{{.CreatedUnix.FormatShort}}</span> — <i class="octicon octicon-info"></i> {{if .HasUsed}}{{$.i18n.Tr "settings.last_used"}} <span {{if .HasRecentActivity}}class="green"{{end}}>{{.UpdatedUnix.FormatShort}}</span>{{else}}{{$.i18n.Tr "settings.no_activity"}}{{end}}</i>
<i>{{$.i18n.Tr "settings.add_on"}} <span>{{.CreatedUnix.FormatShort}}</span> — <i class="octicon octicon-info"></i> {{if .HasUsed}}{{$.i18n.Tr "settings.last_used"}} <span {{if .HasRecentActivity}}class="green"{{end}}>{{.UpdatedUnix.FormatShort}}</span>{{else}}{{$.i18n.Tr "settings.no_activity"}}{{end}} - <span>Read{{if not .ReadOnly}} / Write {{end}}</i>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

text in templates should use i18n locales

@@ -37,3 +39,54 @@ func TestDeleteDeployKeyNoLogin(t *testing.T) {
req := NewRequest(t, "DELETE", "/api/v1/repos/user2/repo1/keys/1")
MakeRequest(t, req, http.StatusUnauthorized)
}

func TestCreateReadOnlyDeployKey(t *testing.T) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you very much for adding tests!

However, our suite of integration tests is becoming quite unwieldy. Would you consider instead writing equivalent unit tests for the DeployKeysPosthandler? See routers/repo/issue_label_test.go for some examples.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wrote the unit tests, but I don't know if it's ok to dump the integration tests.
Those are testing the API and the unit tests the interface.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay, let's leave the integration tests. Eventually, it might make sense to convert our API integration tests to unit tests, but that's for another day. Thanks for adding unit tests!

@vtemian vtemian force-pushed the writable-deploy-keys-671 branch 5 times, most recently from 95c1675 to a1f29cd Compare December 28, 2017 13:10
@vtemian
Copy link
Contributor Author

vtemian commented Dec 28, 2017

@lafriks @ethantkoenig Thanks for code review!
Can you guys take a second look?

@tboerger tboerger added the lgtm/need 2 This PR needs two approvals by maintainers to be considered for merging. label Dec 28, 2017
return fmt.Errorf("Sync2: %v", err)
}

_, err := x.Cols("mode").Update(&DeployKey{
Copy link
Member

@lafriks lafriks Dec 28, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this really needed as NOT NULL DEFAULT when adding column should automatically add default value?

settings.no_deploy_keys = You haven't added any deploy keys.
settings.title = Title
settings.deploy_key_content = Content
settings.is_writable = Allow write access
settings.is_writable_info = Can this key be used to <strong>push</strong> to this repository? Deploy keys always have pull access.
Copy link
Member

@ethantkoenig ethantkoenig Dec 29, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Duplicate of lines 991-992?

@@ -600,6 +600,9 @@ type DeployKey struct {
Fingerprint string
Content string `xorm:"-"`

Mode AccessMode `xorm:"NOT NULL DEFAULT 1"`
ReadOnly bool `xorm:"-"`
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: could we add a ReadOnly() method instead of adding a field?

ID: newDeployKey.ID,
Name: rawKeyBody.Title,
Content: rawKeyBody.Key,
ReadOnly: true,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The ReadOnly field is not stored in the DB, so this condition has no effect. You should instead check the Mode field (which is in the DB). Likewise for the unit test.

@vtemian vtemian force-pushed the writable-deploy-keys-671 branch from fa1a1a1 to dd22f0f Compare December 29, 2017 07:18
@lunny
Copy link
Member

lunny commented Dec 30, 2017

CI failed

@vtemian vtemian force-pushed the writable-deploy-keys-671 branch 2 times, most recently from bb97518 to 0f6ae7c Compare December 30, 2017 12:49
@lafriks
Copy link
Member

lafriks commented Jan 3, 2018

@vtemian To fix tests please add deploy_key.yml in fixtures folder with content like here: https://github.com/go-gitea/gitea/blob/master/models/fixtures/gpg_key.yml

@vtemian vtemian force-pushed the writable-deploy-keys-671 branch from 3081099 to 4771472 Compare January 3, 2018 08:11
@vtemian
Copy link
Contributor Author

vtemian commented Jan 3, 2018

Thanks @lafriks

@codecov-io
Copy link

codecov-io commented Jan 3, 2018

Codecov Report

Merging #3225 into master will increase coverage by 0.41%.
The diff coverage is 50%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master    #3225      +/-   ##
==========================================
+ Coverage   34.67%   35.08%   +0.41%     
==========================================
  Files         278      279       +1     
  Lines       40506    40522      +16     
==========================================
+ Hits        14044    14217     +173     
+ Misses      24394    24203     -191     
- Partials     2068     2102      +34
Impacted Files Coverage Δ
models/migrations/migrations.go 2.89% <ø> (ø) ⬆️
modules/auth/user_form.go 25% <ø> (ø) ⬆️
models/migrations/v55.go 0% <0%> (ø)
routers/repo/setting.go 7.34% <100%> (+2.67%) ⬆️
routers/api/v1/repo/key.go 20.49% <100%> (+20.49%) ⬆️
models/ssh_key.go 39.2% <81.81%> (+7.58%) ⬆️
modules/process/manager.go 76.81% <0%> (-4.35%) ⬇️
models/lfs.go 28.26% <0%> (+2.17%) ⬆️
... and 5 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 70b6c07...b3e094e. Read the comment docs.

@tboerger tboerger added lgtm/need 1 This PR needs approval from one additional maintainer to be merged. and removed lgtm/need 2 This PR needs two approvals by maintainers to be considered for merging. labels Jan 3, 2018
@tboerger tboerger added lgtm/done This PR has enough approvals to get merged. There are no important open reservations anymore. and removed lgtm/need 1 This PR needs approval from one additional maintainer to be merged. labels Jan 4, 2018
@ethantkoenig
Copy link
Member

LGTM

@lafriks
Copy link
Member

lafriks commented Jan 6, 2018

@vtemian you need to rename migration to v55 as other migration was merged already. As soon as you do that this PR can be merged

@vtemian vtemian force-pushed the writable-deploy-keys-671 branch from 5d232ac to 691820b Compare January 6, 2018 20:04
@lafriks
Copy link
Member

lafriks commented Jan 6, 2018

@vtemian please force push to get tests pass, seems to be random failure not related to this PR

@vtemian vtemian force-pushed the writable-deploy-keys-671 branch from 691820b to 440cd76 Compare January 6, 2018 20:28
@lafriks
Copy link
Member

lafriks commented Jan 6, 2018

@vtemian you have renamed existing v54.go that comes from master not yours

@vtemian vtemian force-pushed the writable-deploy-keys-671 branch 4 times, most recently from 3b0686c to c5f6b56 Compare January 6, 2018 21:00
@vtemian vtemian force-pushed the writable-deploy-keys-671 branch from c5f6b56 to b3e094e Compare January 6, 2018 21:02
@vtemian
Copy link
Contributor Author

vtemian commented Jan 6, 2018

@lafriks It should be good now. Thanks!

@lafriks lafriks merged commit e78786e into go-gitea:master Jan 6, 2018
@go-gitea go-gitea locked and limited conversation to collaborators Nov 23, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
lgtm/done This PR has enough approvals to get merged. There are no important open reservations anymore. type/feature Completely new functionality. Can only be merged if feature freeze is not active.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants