Maven release github action#373
Conversation
Use maven-enforcer-plugin to make sure there are no snapshot dependencies when releasing
Not sure which is better, having an indication that a bot did it, or if the user should be linked to it. Looking back, would probably want to know the user that did it, so went with that.
sonar is the one that includes everything that should be released Should consider a profile that defines all modules...
|
Nice improvement! It's different from our usual flow as it will only create a tag (which isn't an issue) but just making sure it's on purpose. Testing it here first before merging it into If we do want to release, we could use something like https://github.com/elgohr/Github-Release-Action or simply call |
Using github cli instead of git to create the release + tag in github
This deploy key should be a secret containing the ssh key that is configured as a deploy key. By using the new rules on github, and allowing bypass for deploy keys in the `main` (or default) branch protection, it should become possible to add the required commits on `main`. This does introduce a new possible vulnerable vector security-wise. If a action is added that contains malicious code that reads the key, it could be exposed and someone could get access to the repeository with that. This risk would be mitigated by restricting actions being updatable by random people, and being aware on this when reviewing, but it does remain a risk. GitHub Apps might be an alternative, but didn't look into that yet. That could at least make it more fine-grained, ensuring only specific actions could be taken.
|
@BertScholten Totally forgot about this.. Should we pick this up again? |
|
@SerhatG Yeah, we could, though not too sure what the way forward is. Looking at last commit message, GitHub Apps might be an option? |
We could somewhat fix the security issues by using the GitHub Actions Policy functionality that is in Preview. I could set that only people in specific teams can run the workflow_dispatch events. I can do this organisation wide for all public repositories. We already use the Github App solution for Jenkins (for the publishing checks bit in our cicd-scripts). So we could do that as well (or a combination of both)·. Shall I pick this up and see if I can make something useful based on your version? |
|
Only having people in specific teams be able to do it sounds good. Using a functionality in preview is a bit risky (might be a bit volatile), but it would beat how we're doing it currently I think. Pinning specific SHA hashes is something that is done at DAT as well, though not entirely sure how that's being kept up to date. Vaguely remember something about dependabot doing checks on that, could have a look if you want? I'd be fine with you picking this up, I don't have the permissions to change anything in settings anyway so all I can do is fiddle around on my own fork ;) |
2 participants
In an attempt to automate releases a bit more, reckon that for our public repositories we might as well use a github action.
Could move part of this to our github-actions repo as well, but perhaps first lets check if it actually works the way we want?
Testing it might be a bit tricky. Currently there is no snapshot dependency, so it should just work, but would want to check that it does actually stop when there is such a dependency, for instance if the root pom used is on snapshot.