Draft: Make Wrapper validator self executable and GitLab CI ready

[aepfli]

Not all OS Projects are using GitHub and have the benefit of using
GitHub Actions. With this changes the Wrapper-Validation-Action
is executable on its own. It will use command line options for
configuration instead of GitHub Action Inputs.

Additionally a GitLab CI template was added and a Dockerfile for
building a ready to use Dockerimage.

Notes

I started this, because we are currently also evaluating this option to be used with GitLab CI, and currently i found no suitable solution. The changes themselves seem to be not that critical, but as their are a few questions to be resolved first, i marked this PR as Draft. It is also not fully tested, first i want to validate my approach with the maintainers

Questions

• Is it a feasible and wanted approach, which i am proposing?

• if this is a suitable approach, how should we handle the creation of the docker image and more precisely the versioning?

  • we would also need to tag the docker image corresponding to the git tag
  • we would need to adapt the WrapperValidation.gitlab-ci.yml to point to the right tag on each release (alternatively i could create a fork on GitLab.com for easier integration - the include would be easier to read)

• if it is not feasible. I prepared everything to be working out of this project, Dockerfile, GitLab-Template, etc. Theoretically i can migrate this into a fork on GitLab as mentioned earlier - i could host the docker image and the templates there, and only keep the CLI changes in here.

• how does GitHub like it when an alternative product is mentioned in the ReadMe of an Action?

possible improvements

• The changes are not ideal, as there are currently 2 files to maintain for the defaults - action.yml and package.json - it does not matter as the options are not that big currently, but this can lead to confusion in the future, maybe generate one of them during build based on the other? added
• The Dockerfile now contains a lot, there might be improvements for .dockerignore
• The output is still formatted for GitHub Action - but as a first working draft i think this is fine.

TODOS:

• command line inputs for the tool
• alternative ENV inputs for the tool
• gitlab ci tests
• docker image build and upload
• clarification for docker image upload (where should it be, and also the yml file needs to be adapted) - see evaluation section
• update ReadMe
• clarification of best way to import it into GitLab CI the raw-github url is not that maintainer friendly - see evaluation section

Evaluations

actual GitLab Pipeline instead of gitlab-ci-local

evaluating if https://docs.gitlab.com/ee/ci/ci_cd_for_external_repos/github_integration.html makes sense instead of using gitlab-ci-local

Problems i see:

• who will set this up? is there a gradle group or something official, if we want to use this.

• who will be the owner?

• whose PAT will be used for the integration?

• benefit in usage for gitlab-ci as there is a project which can be used, instead of a remote url

  include:
      - remote: <github raw url to file>
  # versus
  include:
      - project: <gitlab project path>
        file: WrapperValidation.gitlab-ci.yml
  

Both solutions are feasible, and implementation wise not a big difference - the questions are more security like.

Docker registry

1. it would be good to have this public available via docker hub
2. alternatively we could use github registry or GitLab registry

The docker image itself can be used standalone, therefore a public and easy to use registry would be the best way.

docker run --rm -v "$(pwd):/app" -it wrapper-validation:latest --min-wrapper-count 10

[JLLeitschuh]

I'm not inherently against this idea if it's a lightweight addition and it includes some kind of testing. I just don't think that either @eskatos or I have the capacity to maintain this GitLab support, so we'd need to rely upon the community for future maintenance of this feature.

[eskatos]

Same feeling as Jonathan, it sounds like a good idea to use the same codebase to support more CI environments. Automated testing/releasing and maintenance burden would be my only concerns.

[aepfli]

thoughts regarding this:

• testing everything inside github with aciton should be not a problem

  • node application on its own no problem
  • github action no problem
  • docker image i am not sure how to best test this
  • testing gitlab CI could be done by https://github.com/firecow/gitlab-ci-local - which should be fairly easy with GitHub Actions

• releasing

  • well there is currently a lot of manual effort, maybe we want to also think about automating this (extra task)
  • for GitLab Ci i would actually create a fork, with mirror and modify the files accordingly via GitHub Actions before commiting
  • for the dockerfile i am not sure, there is the question of docker hub or ghcr.io - i do not have prefernces, but the tagging might be complicated - if we stick to existing conventions, if we decided to use the ref as a tag, i think there is no issue in that like image:master, image:gittag - but there is room for improvement on a later stage.
  • additionally there is also the possibility to release an npm package, so people can use it with npx

i am willing to support and help and implement regarding that - because i think this could be beneficial for all the other CI tools outside there too

[Ssempijja-h]

@[Seeme-seeyou](http://seeme-seeyou.com)

[aepfli]

@eskatos @JLLeitschuh - i can understand your concerns regarding support from the community - i am not a community but i do not plan to abandond my contributions :)

To ease the pain regarding testing concerns, i added an docker image build, which is testing the whole image with a tool to execute gitlab-ci locally. therefore i added additional tests, some are not ideal, like the once were i expect a failure, but i am also checking now for min wrapper success and error cases as well as for invalid wrapper error cases. can be seen here: https://github.com/aepfli/wrapper-validation-action/runs/3898016798?check_suite_focus=true

now comes the tricky part, the releasing - based on how actions are release, it would imply code changes within one file - the version of the docker image, it should match the tag (the build is ready for that).

validate-wrapper:
  stage: .pre
  image:
    name: ghcr.io/aepfli/wrapper-validation:<CHANGE VERSION HERE>
    entrypoint: [""]
  script:
    - wrapper-validation

I definitely want to bring this somewhat to an successful end, because i do think other projects on gitlab can benefit from this. So i am looking forward to your feedback/input

[JLLeitschuh]

I'm asking internally if we already have a Gradle account on DockerHub we could use to publish the Docker container too.

Ideally, if it was made such that publishing an updated version of this project only added like 1 or 2 steps, that would be fine. For example, simply reving a version inside a file would be fine. I don't want us to have to publish anything from our local machine though (ie run docker publish). That should be done by CI for us.

[JLLeitschuh]

We do indeed have an account: https://hub.docker.com/u/gradle

[aepfli]

i am checking the failing ci step, and it seems like that the tool i used gitlab-ci-local is not able to handle git refs from pull requests.

• I can remove gitlab-ci-local -> than we might want to start a fork on GitLab which will also report the build results to this project here on gitHub (not sure if i should be the one doing this)
• or i make this work in gitlab-ci-local - i opened an issue already, and i will try to provide a solution for that

[aepfli]

i fixed the issue with gitlab-ci-local, so GitHub Actions should now pass.

How do we want to continue on this, what do you need from me to finish this, or to get this merged?

• should i get it ready to use secrets to push to docker hub?
• do we need any kind of additional documentation?
• Regarding readme. should we add a section at the bottom on how to use this with docker standalone, and one for gitlab ci? or do you prefer subpages for that?

[aepfli]

i fixed the issue with gitlab-ci-local, so GitHub Actions should now pass.

How do we want to continue on this, what do you need from me to finish this, or to get this merged?

• should i get it ready to use secrets to push to docker hub?
• do we need any kind of additional documentation?
• Regarding readme. should we add a section at the bottom on how to use this with docker standalone, and one for gitlab ci? or do you prefer subpages for that?

@JLLeitschuh (sorry for shameless pinging)

[JLLeitschuh]

@JLLeitschuh (sorry for shameless pinging)

It happens, I get it.

should i get it ready to use secrets to push to docker hub?

This would be appreciated. I don't have the time to do this myself. @wolfs @blindpirate just want to check, it's fine if we have the publishing pipeline for this setup through GitHub actions right? I don't have the time to set this up personally using TeamCity, which I recognize you'd probably prefer.

If this is being published to GHCR instead of Docker Hub, I guess this is probably fine imho. Do GH actions have the permissions needed to publish to GHCR or would we need a token with additional permissions?

do we need any kind of additional documentation?

For the README, if there are additional configuration options beyond just specifying the dependency, then yes, an example of how to configure the action would be really good.

Regarding readme. should we add a section at the bottom on how to use this with docker standalone, and one for gitlab ci? or do you prefer subpages for that?

Personally, a single README for all information seems fine IMHO. I don't like hiding information.

[blindpirate]

it's fine if we have the publishing pipeline for this setup through GitHub actions right? I don't have the time to set this up personally using TeamCity, which I recognize you'd probably prefer.

If this repository has been set up to use GH actions since day 1, I think it's fine to continue using it for CI and publishing.

[blindpirate]

Shall we change this to ghcr.io/gradle if we use ghcr.io/${{ github.repository_owner }}/$IMAGE_NAME in the publish job?

[aepfli]

yes we can, this is currently just for evaluation, that it works, and to show the greater picture - the question is, what kind of hosting for the docker image we will be using.

• ghcr
• docker hub
• gitlab registry (with an automatically updated fork of this project)

There are multiple possible solutions, and i am open to any of those ;)

[JLLeitschuh]

I don't think any of us have enough experience with GitLab to make any sort of evaluation as to the value of picking one vs the other. I think that a clear list of pros-and cons would be useful. I'd defer to your suggestion here most likely.

[aepfli]

Comparison of Registries for the docker image

Options:

• Docker Hub
• GitHub Docker Registry
• GitLab Docker Registry

Docker Hub

Pros:

• easiest accessible registry - image name would be just gradle/wrapper-validation
• account does already exist
• easy do apply to all kind of docker based CI systems

Cons:

• secrets need to be added to GitHub for pushing*
• pricing - i have no clue about the impact regarding this

• as far as i understood, there is already a teamcity server in place, which pushes the other docker images, but gradle wrapper validation is using GitHub Actions, so we need to somehow provide this credentials.

GitHub Docker Registry

Pros:

• easily included in the GitHub Action
• Registry is already existing, as it is coupled to the repository
• as long as it is public the registry is free:

  GitHub Packages usage is free for public packages. For private packages, each account on GitHub.com receives a certain amount of free storage and data transfer, depending on the product used with the account. Any usage beyond the included amounts is controlled by spending limits. - https://docs.github.com/en/billing/managing-billing-for-github-packages/about-billing-for-github-packages

Cons:

• image name for includes will not be as short as intended
• not as easy to find, people will search docker hub for such images

GitLab Docker Registry

Pros:

• Registry is easily included into GitLab Actions
• Due to the Fork (see cons) the include statement will be much clearer for gitlab ci

   include:
   	- remote: https://raw.githubusercontent.com/gradle/wrapper-validation-action/master/WrapperValidation.gitlab-ci.yml

  turns into

   include:
   	- project: <Project Path eg. gradle/wrapper-validation - depends on availability of names>
   	  file: WrapperValidation.gitlab-ci.yml

• docker image creation could be also done via GitLab Registry
• as longas it is public, registry is free

Cons:

• Fork needs to be created on GitLab.com side (i can maintain and create it) - i would recommend a fork which is autmatically updating itself.
• Additional indirection with GitLab
• image name for includes will not be as short as intended
• not as easy to find, people will search docker hub for such images

Recommendation

There are two scenarios, which i can recommend for now, which actually could also be applied in parallel

1. i would go with GitHub Registry - it is easy to apply and as a first step a good evaluation. We will see adaption etc.

2. i would also prepare a GitLab CI file to push it to a gitlab registry, I can create a group and a fork, which automatically updates from github (so source of truth will still be GitHub) - this would allow users to use the easier and better readable approach for includes.

I will prepare 1. during the christmas holidays, and i will also update the readme. - we can then decide how to proceed in the new year.

[JLLeitschuh]

I think I agree with your recommendation to go with the GitHub Registry. Thank you for writing up this thorough assessment, much appreciated.

[wolfs]

If this is being published to GHCR instead of Docker Hub, I guess this is probably fine imho.

If we use GHCR, may we run into problems with pricing and us paying a lot for other folks using the docker image? I saw that the use from within GH actions is free, though for anything else we would pay at some point.