-
Notifications
You must be signed in to change notification settings - Fork 170
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
feat: Add create and remove template tag routes #647
Conversation
}) | ||
]) | ||
.then(([pipeline, template]) => { | ||
// Check for permission |
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.
There should be a check for the template
existing
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 don't think it's necessary because of our logic. templatetag
can't be created if the template
itself doesn't exist. There is already a check if templateTag
exists. If templateTag
exists, then template
should exist.
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.
- Create template
- Create tag
- Delete template
- Lookup tag
- 500 error
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.
Deleting a template does not clean up the tags. And since you can operate on tags independently from templates, that delete operation isn't there yet.
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.
Deleting a template should delete the tags that are associated with it. It doesn't make sense to keep a tag that references something that doesn't exist. Just like how deleting a pipelines should delete all its jobs & builds.
Also, we don't have delete template at the moment.
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 can add it for extra safety, but it will never reach the code with our current design.
plugins/templates/createTag.js
Outdated
const schema = require('screwdriver-data-schema'); | ||
const urlLib = require('url'); | ||
|
||
/* Currently, only build scope is allowed to tag template due to security reasons. |
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.
👍 good comment
plugins/templates/createTag.js
Outdated
pathname: `${request.path}/${tag.id}` | ||
}); | ||
|
||
return reply(tag.toJson()).header('Location', location).code(201); |
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.
Hm should this return the template
or the templateTag
or some combination of the two?
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 think it makes more sense to return just the tag. If it returns the template
itself, it might be confusing to the users: "Did I just create this template?"
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.
Hm. If the object returned has the template info AND the tag would that be more clear? Or still confusing
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.
Generally I think it should return what GOT CREATED. That's why I don't want to include the template information since the template is not created, the tag is created. For a GET
it makes sense to return the template.
What are others' opinions on this?
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 think template name, version and tag together should be good enough.
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.
No preference here
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.
Don't mind any way you end up choosing, as long as the UI can consume it easily. If you want my opinion, I would have expected the resource that was created to be returned.
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.
update README?
plugins/templates/removeTag.js
Outdated
const templateFactory = request.server.app.templateFactory; | ||
const templateTagFactory = request.server.app.templateTagFactory; | ||
const pipelineId = request.auth.credentials.pipelineId; | ||
const config = request.payload; |
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.
Is it weird to pass in a payload for a DELETE
?
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 think it is unusual, but not forbidden according to RFC 7231.
A couple posts related to this:
- https://stackoverflow.com/questions/299628/is-an-entity-body-allowed-for-an-http-delete-request
- Using request body (json payload) for DELETE http requests zalando-stups/lizzy#151
I would say it's weird and we should avoid it if we can. But I think in this case, it makes sense to send a payload with it. An alternative would be delete templates/tags/{name}/{tag}
? I'm not sure if that's weird either. What do you think?
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 think to it would be safer for us to use the /templates/tags/{name}/{tag}
endpoint instead of getting the data from the payload. Just in case other browsers drop the payload. What do you think?
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.
The RESTful endpoint would be DELETE /templates/{name}/tags/{tagName}
. You should be able to fetch the pipeline data from the template data and the JWT when comparing for authorization [build scope].
Alternatively, this could be DELETE /templates/{name}/{tagName or version}
if it was less restful, but this adds a layer of confusion.
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.
Let's go with DELETE /templates/{name}/tags/{tagName}
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.
@petey Should the GET
endpoint for template tags be GET /templates/{name}/tags/{tagName}
then?
Update: keeping the GET /templates/{name}/{versionOrTag}
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.
plugins/templates/README.md
Outdated
@@ -73,3 +73,26 @@ Example payload: | |||
} | |||
} | |||
``` | |||
|
|||
#### Create a tag for a template version |
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.
How about update / retagging?
e936260
to
0d1f988
Compare
Also do we do any checks to make sure the build that deletes the tag is the one that created the tag? Or can anyone create/delete a tag right now? |
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.
@tkyi Yes it does check for permission. It's specified in the README:
In the code: |
#### Get all templates | ||
`page` and `count` optional | ||
#### Template | ||
##### Get all templates |
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.
Hm this heading style gets interesting because it looks smaller than the Arguments
|
||
return Promise.all([ | ||
pipelineFactory.get(pipelineId), | ||
templateFactory.get({ name, version }), |
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.
Should this be getTemplate
?
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.
Should be get
, since we want to get the exact version. And getTemplate
will be refactored into string only later.
93d92be
to
726ea94
Compare
|
||
You can get a single template by providing the template name and the specific version or the tag. | ||
|
||
`GET /templates/{name}/{tag}` or `GET /templates/{name}/{version}` | ||
|
||
**Arguments** | ||
###### Arguments | ||
|
||
'name', 'tag' or 'version' | ||
|
||
* `name` - Name of the template | ||
* `tag` - Tag of the template (e.g. `stable`, `latest`, etc) | ||
* `version` - Version of the template |
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.
Maybe we could call out that we'll autobump versions for them when they create templates.
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.
feat: Add create and remove template tag routes
Context
This PR allows tagging a template, similar to how docker tagging works.
Example:
Objective
Add 2 routes for template tagging: CREATE and DELETE.
UPDATE uses the same route as CREATE: send a
PUT templates/{templateTag}/tags/{tagName}
with the payload as:{version}
instead of the usual/id
, since it doesn't make sense that users need to look up theid
to update.DELETE:
DELETE templates/{templateTag}/tags/{tagName}
Notes: This only allows
build
scope to tag template due to security reasons. It will check if the build belongs to the pipeline that publishes this template. If not, then the build is not allowed to tag the template.References
#616