Sdkman, Kotlin and kscript must be installed, the code needs to be retrieved from the repository and both kscript scripts have to be packaged. Hosted with ❤ by GitHub Action’s metadataįrom the start what I wanted for this action was to be as autonomous as possible leaving very little responsibilities to the consumer and allowing her to just plug it in and watch it play.įor that the only input the action needs is a token, for allowing the kscript scripts to communicate with the API, which will most likely be the default secrets.GITHUB_TOKEN making the action’s usage as simple as adding the following lines in your workflow: - uses: $ Docker imageĪ lot of things must happen in order to have the action ready to run. kts file where I defined the external dependencies and included the.
I created my tests (using all my favorites like junit5, hamkrest and MockWebServer) and from that I created. So what I ended up doing was to act as if I was in a Kotlin project. I like kscript since I can write things fast, easy and with all the libraries that I know but I also like writing test first and that proved to be quite difficult. Again a standalone binary was created and put in the image. The third and final part is again a kscript script that uses the report created before and GitHub’s REST API to make a PR line comment for every ktlint error that is part of the PR’s diff. Ktlint is being called with the -reporter=json parameter in order to create a JSON report. The second part is a combination of bash commands that execute the ktlint binary by passing to it the results of the first part. When I was happy with the resulted script I used its -package option to create a standalone binary and copy it in the action’s Docker image. For that I used kscript and I was able to leverage all the libraries that I was accustomed to, like Retrofit and Moshi. The first part is responsible for using GitHub’s REST API to collect all of the PR’s changes and then keep those that are in Kotlin files and were added or modified. The runner makes sure that the working space is being mounted to the container (in the state that it was just before the action is started) along with all the environment variables and the inputs the action needs.
All you have to do is to make sure that the action’s executable parts are being copied in the container and that are called upon its start. In our case there is also a third ingredient, a Dockerfile or a docker image which is used by the action’s runner to create a container and execute the action’s code inside it. the action’s metadata, a file called action.yml which is placed in the root folder of your project and defines how the action will run and what inputs/outputs it has.In all three ways the main two ingredients are: There are three ways to create an action but only the one using Docker allows us to use the language we want.
0 kommentar(er)
