Currently docker images are not versioned which can be an issue going further

[preetkaran20]

Is your feature request related to a problem? Please describe. Docker images for VulnerableApp have just 2 versions latest and unreleased. It should be latest (whcih is unreleased) and specific tags for released versions.

For more information about the existing images: https://hub.docker.com/r/sasanlabs/owasp-vulnerableapp

How do we create images ? we have a Github action for creating and pushing docker images: https://github.com/SasanLabs/VulnerableApp/blob/master/.github/workflows/docker.yml, we use a tool called jib for this

[merry-degaga]

Hello,

I would like to take on this issue.

I was looking into GitHub Workflow, actions, jib, the current docker.yml, docker hub and had a few questions.

1. To make sure I understand the issue, the Docker 'unreleased' tag is on the most recently pushed image (that has not been released).
2. Then, did you want the Docker 'latest' tag on the most recently pushed image (it can be either released or unreleased)? Or should it always be tagged to a released version?
3. I was also looking into gitversion to automate the semantic versioning. There is a GitHub action available for that or would you rather have developers create tags that the workflow can use.
4. Currently the workflow is triggered when a push to main occurs. What do you think of having this triggered instead, when a pull request is approved?

Thank you

[preetkaran20]

@merry-degaga sorry, I missed your message. Are you working on this task ?

[preetkaran20]

Hello,

I would like to take on this issue.

I was looking into GitHub Workflow, actions, jib, the current docker.yml, docker hub and had a few questions.

1. To make sure I understand the issue, the Docker 'unreleased' tag is on the most recently pushed image (that has not been released).

Yes, unreleased is the not yet release docker image.

2. Then, did you want the Docker 'latest' tag on the most recently pushed image (it can be either released or unreleased)? Or should it always be tagged to a released version?

I think latest should be released tag.

3. I was also looking into gitversion to automate the semantic versioning. There is a GitHub action available for that or would you rather have developers create tags that the workflow can use.

How would github action know, we want to release a newer version ?

4. Currently the workflow is triggered when a push to main occurs. What do you think of having this triggered instead, when a pull request is approved?

I think we should always triggered on merge on the main branch. For PR docker's, we are not getting any requirement till now.

Thank you

[merry-degaga]

@merry-degaga sorry, I missed your message. Are you working on this task ?

Yes, I can work on this, thank you

[merry-degaga]

3. I was also looking into gitversion to automate the semantic versioning. There is a GitHub action available for that or would you rather have developers create tags that the workflow can use.

How would github action know, we want to release a newer version ?

The github action gitversion uses the github action checkout@v2 with a fetch-depth: 0 to grab all tags. Using the commit message from a merge request, a contributer can enter in either +semver:major | minor | patch. Patch is the default incremented value if +semver: is not included in the commit message. I included another github action that will update the tag as well in GitHub, that is the softprops/action-gh-release@v1 action.

[merry-degaga]

So far the functionalities I am able to set up is: On a push event to main, given a contributer includes +semver:major | minor , this will update both the Github tag and build and push docker image with the version tag, and latest tag. On a push event to main, given a contributer does not include +semver:major | minor, this will automatically increment the semantic version's patch value and update both the Github tag and build and push docker image with the version tag and latest tag.

Does this meet your expectations? If so, I will put in a pull request. Thank you.

[preetkaran20]

@merry-degaga sounds good. Please raise the PR and we can do modifications there if required.

thanks, Karan