Bump docker-workflow from 1.18 to 1.21

[dependabot-preview]

Bumps docker-workflow from 1.18 to 1.21.

Release notes

Sourced from docker-workflow's releases.

1.21 - Windows Docker Agents Support 🚀

• Introduce support of Windows Docker agents (#184) @​rbutcher @​casz
• Allow running Declarative Pipeline on Windows Docker agents with this plugin (#184) @​rbutcher @​casz

pipeline {
  agent {
    docker {
      label 'windows'
      image 'mcr.microsoft.com/powershell'
    }
  }
}

1.20

🚀 New features and improvements

• Add Container ID detection for GitHub Actions (#187) @​jonico

📝 Documentation updates

• Move changelog to GitHub, add badges for the plugin site and release stats (#192) @​oleg-nenashev
• JENKINS-59172 - Use GitHub as a source of documentation on plugins.jenkins.io (#191) @​oleg-nenashev

👻 Maintenance

• Enable Release Drafter in the Repository (#190) @​oleg-nenashev
• Use try-with-resource in 'Dockerfile#parse()' (#186) @​stefanbirkner

Commits

• dfe3ed4 [maven-release-plugin] prepare release docker-workflow-1.21
• 6d01b80 Merge pull request #184 from 3shapeAS/features/windows_slaves
• 19ebb47 [maven-release-plugin] prepare for next development iteration
• 3108819 [maven-release-plugin] prepare release docker-workflow-1.20
• 3909e58 Merge pull request #192 from jenkinsci/changelog
• 6f415b2 Merge pull request #190 from jenkinsci/release-drafter
• 815419f Merge pull request #187 from jonico/patch-1
• cf1948e Merge pull request #191 from jenkinsci/plugin-docs
• 5da9410 Move changelog to GitHub, add badges for the plugin site and release stats
• 58a358e [JENKINS-59172] - Use GitHub as a source of the plugin's documentation on plu...
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
• @dependabot use these labels will set the current labels as the default for future PRs for this repo and language
• @dependabot use these reviewers will set the current reviewers as the default for future PRs for this repo and language
• @dependabot use these assignees will set the current assignees as the default for future PRs for this repo and language
• @dependabot use this milestone will set the current milestone as the default for future PRs for this repo and language
• @dependabot badge me will comment on this PR with code to add a "Dependabot enabled" badge to your readme

Additionally, you can set the following in your Dependabot dashboard:

• Update frequency (including time of day and day of week)
• Pull request limits (per update run and/or open at any time)
• Automerge options (never/patch/minor, and dev/runtime dependencies)
• Out-of-range updates (receive only lockfile updates, if desired)
• Security updates (receive only security updates, if desired)

[jglick]

Oops, looks like using $BUILD_TAG as a cluster name was not a good idea. I was hoping to avoid potential contamination between builds running on the same node, but I can do it differently.

[jglick]

@dependabot rebase