feat: allow to pass spec inline

[sh0rez]

This allows to pass the contents from spec directly from drone.yml, for use
with autogenerated drone configurations.

See #27 (comment) for details why this is required.

Fixes #27

[tboerger]

@drone-plugins/maintainers what do you think about that? IMHO it doesn't make a big difference if a previous step simply generates the manifest template which gets used by this plugin or if it's assigned as a multiline value.

I personally would prefer the previous step, showcased at #27 (comment).

[bradrydzewski]

I do not really have strong opinions.

I read the comment in issue #27 and I think the only question I have is how you plan on generating the string with jsonnet? Have you tested generating the string to ensure it works as expected before we modify the plugin accordingly?

In terms of implementation, I think if we allow reading from an inline string, we should use a different attribute name. I know in the past we have re-used the same attribute, however, in retrospect I think being more explicit is better.

for example:

spec: path/to/manifest.tmpl
spec_string: |
  image: ...
  manifests: ...

[bradrydzewski]

@tboerger this is more of an aside, but one thing I noticed with the manifest plugin is that we tend to re-use the same templates for most (all?) of our projects and we only change the image name. Is there a way to represent this in yaml (sort of like auto_tag) so we can make the template optional?

[tboerger]

Currently the template don't support the auto tagging, if we add that to the template it would be doable for most parts, but our windows versioning doesn't match the exact naming and I haven't checked how manifest is handling the arm versions without the template file.

[tboerger]

Since we are already doing this string or read from file stuff on the github release plugin I think I'm fine with this change.

[sh0rez]

What's the state of this? Can it be merged?