Hey Alex, Im happy to see you experimenting with these tools Keep in mind that balena-versionist is simply a wrapper around versionist, what it does is to essentially build a versionist.conf.js file on the fly, from your repo.yml configuration. It is opinionated, in the sense the versionist.conf.js that comes out, will follow our own conventions, and may also assume some things that happen through our CI system. This is the problem you are running into right now, if you have a look at the previous step (run balena-versionist) you will see an error reported
at ChildProcess.exithandler (child_process.js:295:12)
at ChildProcess.emit (events.js:223:5)
at maybeClose (internal/child_process.js:1021:16)
at Process.ChildProcess._handle.onexit (internal/child_process.js:283:5)
Not sure why this is marked as successful, but this means that versionist failed to run. The reason is that the configuration that is generated on the fly, will assume that a github release (or a tag) matching the latest documented version exists (this is done because versionist wants to process all the “new” commits, from the latest one to the latest documented version), and will error out if such reference is not found.
You can manually create a reference to have this work, I would also suggest adding another step after pushing the changes, that adds the tag and pushes that back to origin as well. Keep in mind the tag should use the same version format that appears in the changelog, so in this case it would be v0.0.2.
Hope this information is helpful, let me know if you need any more help setting this up.
My next problem: I need balena ci checks. There are some, which ensure that the commits have Change-type: . The official scripts of balena are here: https://github.com/balena-io/scripts
I know that balena is using alpine linux in their runners. But i don´t know how to use it in github actions. Can you help me?
@nazrhom i spotted another issue, while trying to integrate the balena ci-checks. There has to be a .version file in the .git directory, but it is missing and i don´t know how to get it. Here is a reference to it:
@AlexProgrammerDE our CI system is based on concourse We have a custom github resource that will add the .git/.version file which contains metadata about the repository. Unfortunately both the resource and implementation of our pipeline are private, so I can’t share links to those directly, but I can give you an idea on how it is implemented.
When a PR is opened, different jobs will be triggered, some steps are common to all repos while other depend on what is specified in repo.yml. Each job can be set to automatically create success/failed checks on the PR that triggered it, you will notice checks follow the conventions balenaCI/job/task based on the task (which is a step in a job in concourse-lingo).
Creating a status check should be pretty easy, as you are setting this up as github actions I think you should have access to the required metadata. have a look at this for more info.
Also have a look at balena-commit-lint we use this in our job that checks commits to make sure the commit contains a change-type amongst other things.
@AlexProgrammerDE
That sounds great. Let me know if you need any more pointers or want to discuss any approaches to this. I am the maintainer of our CI system, and am very interested in making it more accessible to users outside balena so any feedback from this is invaluable
We run versionist on every PR and store the result in what we call a build branch this will contain the commit with the version bump and any metadata (changelog, ecc) that is generated from the PR. Once the PR is merged we replay that commit on top of master.
As far as the issue you report, I am not sure what is happening there. I tried running it locally from your PR and the commit is reported as valid
nazrhom at fwr in ~/.../balena-github-actions
$ git checkout origin/AlexProgrammerDE-patch-5
Previous HEAD position was bdc8bc1 v1.1.2
HEAD is now at 6e3eab3 Rename test to test1
nazrhom at fwr in ~/.../balena-github-actions
$ commit=$(git show $(git rev-parse --verify HEAD) -s --format=%B)
$ resin-commit-lint "${commit}"
Valid
nazrhom at fwr in ~/.../balena-github-actions
$ resin-commit-lint "${commit}" -c config.json
Valid
I tried to fork and run a couple of tests locally, but there seems to be some issue with github actions on my account I have to get sorted first
In the meantime I would suggest checking that the commit in $commit is actually the one we expect, and that the config path is being picked up correctly (maybe try without the option, which should use the default one)
@nazrhom i found the issue. I runned echo "${commit}" as a part of the workflow and it resulted in:
Merge 6e3eab36d15abb19b0cea2631ab64491e0161126 into d98f4dae685061caf068904e0f53087ad5d2528b
I changed: commit=$(git show $(git rev-parse --verify HEAD) -s --format=%B)
to: commit=$(git show $(git rev-parse --verify HEAD~1) -s --format=%B) and it worked fine.
With that done i am able to implement it everywhere i want.
Thanks for all. If i got in the future more problems i know who to contact.
Bye
PS. I think license and readme checks are uselles for me. Because i would know if it gets deleted with a PR.
Keep in mind that balena-versionist is simply a wrapper around versionist, what it does is to essentially build a versionist.conf.js file on the fly, from your repo.yml configuration. It is opinionated, in the sense the versionist.conf.js that comes out, will follow our own conventions, and may also assume some things that happen through our CI system. This is the problem you are running into right now, if you have a look at the previous step (run balena-versionist) you will see an error reported
It works like the balena ci and has no problems.
