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:

• [x] command line inputs for the tool
• [x] alternative ENV inputs for the tool
• [x] gitlab ci tests
• [x] 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.

[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.