-
Notifications
You must be signed in to change notification settings - Fork 57
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Draft: Make Wrapper validator self executable and GitLab CI ready #50
base: main
Are you sure you want to change the base?
Conversation
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.
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. |
141bf95
to
9128da9
Compare
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. |
thoughts regarding this:
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 |
9128da9
to
9199393
Compare
|
@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 |
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. |
We do indeed have an account: https://hub.docker.com/u/gradle |
i am checking the failing ci step, and it seems like that the tool i used
|
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?
|
@JLLeitschuh (sorry for shameless pinging) |
It happens, I get it.
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?
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.
Personally, a single README for all information seems fine IMHO. I don't like hiding information. |
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. |
validate-wrapper: | ||
stage: .pre | ||
image: | ||
name: ghcr.io/aepfli/wrapper-validation:latest |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shall we change this to ghcr.io/gradle
if we use ghcr.io/${{ github.repository_owner }}/$IMAGE_NAME
in the publish job?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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 ;)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
turns into
include: - remote: https://raw.githubusercontent.com/gradle/wrapper-validation-action/master/WrapperValidation.gitlab-ci.yml
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
-
i would go with GitHub Registry - it is easy to apply and as a first step a good evaluation. We will see adaption etc.
-
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think I agree with your recommendation to go with the GitHub Registry. Thank you for writing up this thorough assessment, much appreciated.
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. |
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?
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 -addedaction.yml
andpackage.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?TODOS:
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
Both solutions are feasible, and implementation wise not a big difference - the questions are more security like.
Docker registry
The docker image itself can be used standalone, therefore a public and easy to use registry would be the best way.