Imagine a drone-plugins/drone-hugo release shipped with hugo version 0.40.
If the attribute version is not set, the binary shipped in the container is used (v.0.40). If the version attribute is set, the defined hugo version is downloaded and used instead of the version in the container (v.0.39). So the example above will result in the pipeline output:
Downloading hugo version v0.39...
Using hugo v0.39...
Contains some verification checks
--destination cbrgm.de
Executing: hugo --destination cbrgm.de
Building sites …
| EN
+------------------+----+
Pages | 80
Paginator pages | 2
Non-page files | 0
Static files | 26
Processed images | 0
Aliases | 34
Sitemaps | 1
Cleaned | 0
Total in 93 ms
I also suggest tagging the new drone-plugins/drone-hugo images by plugin version instead of hugo version. So the new images will be available as plugins/drone-hugo:1.1 (and so on...).
I have defined a new attribute to set the Hugo version in the pipeline step - thanks to @tboerger for the idea!
This PR allows you to set the hugo version to be used over the attribute
version
.Imagine a drone-plugins/drone-hugo release shipped with hugo version 0.40. If the attribute
version
is not set, the binary shipped in the container is used (v.0.40). If the version attribute is set, the defined hugo version is downloaded and used instead of the version in the container (v.0.39). So the example above will result in the pipeline output:I also suggest tagging the new drone-plugins/drone-hugo images by plugin version instead of hugo version. So the new images will be available as plugins/drone-hugo:1.1 (and so on...).
I'm excited for your review!