right now people have to run the release rake task. That will push a tag and commit. That's bad because some people have their local repo setup in a wrong/different/odd way so the commit ends up in their fork. Also we cannot enable branch protection for master. I would like to see an optional github action that can run the rake task. and I would like to rethink the bumping to -rc0 after a release. IRC discussion:
2024-06-13 11:06:43 ewoud one problem with required checks: our release workflow pushes a commit that bumps the release directly to master, which required checks can refuse
2024-06-13 11:06:54 ewoud has that been resolved?
2024-06-13 11:07:27 Zhenech nope
2024-06-13 11:09:02 bastelfreak maybe we drop that approach
2024-06-13 11:09:36 bastelfreak it really confuses people from time to time
2024-06-13 11:10:52 Zhenech the bumping?
2024-06-13 11:11:14 bastelfreak yes
2024-06-13 11:11:31 bastelfreak or can't we enforce checks for PRs only?
2024-06-13 11:13:23 ewoud with Foreman we don't bump and generally it doesn't lead to problems AFAIK
2024-06-13 11:13:40 bastelfreak yep
2024-06-13 11:14:10 bastelfreak and when we drop that we could set or HEAD branch to protected...
2024-06-13 11:14:32 ewoud I wouldn't mind
2024-06-13 11:14:48 ewoud perhaps raise and issue and send it on the mailing list for additional visibility?
2024-06-13 11:14:55 bastelfreak yep
2024-06-13 11:15:22 Zhenech I find it useful, as it allows to differentiate "did a run use the released version or git HEAD", but wouldn't see that as a blocker
2024-06-13 11:15:42 Zhenech (a run of a module that depends on us, that is)
2024-06-13 11:16:12 bastelfreak for released version you can also refer to the last tag, would that help?
2024-06-13 11:16:19 bastelfreak (nor sure if I understand your usecase)
2024-06-13 11:16:38 ewoud perhaps first start with a description of the problem (we want branch protection, but bumping in releases is a problem) rather than a solution (we want to dr
2024-06-13 11:16:49 bastelfreak that was my idea, yes
2024-06-13 11:17:07 Zhenech bastelfreak, usecase: I look at the beaker output of $random module and see puppet/systemd rc0 -- I know it installed it from git vs from forge
2024-06-13 11:17:08 VoxBot <bunsen> See the `puppet-systemd` module at <https://forge.puppet.com/puppet/systemd?src=slack&channel=voxpupuli>
2024-06-13 11:17:17 bastelfreak ahhhh
2024-06-13 11:17:18 bastelfreak yes
2024-06-13 11:17:41 ewoud I wonder if we could patch it dynamically somehow
2024-06-13 11:18:06 ewoud if it's just acceptance tests, we could do that
2024-06-13 11:18:31 bastelfreak we could also do releases via github actions and raise a PR that bumps it to -rc0
2024-06-13 11:19:25 ewoud https://github.com/voxpupuli/voxpupuli-acceptance/blob/e1ca6eaebef38f6ba47c1a2af12cc20480f2865d/lib/voxpupuli/acceptance/fixtures.rb#L48-L59 is where we buil
2024-06-13 11:20:33 ewoud you could write some logic that checks if .git exists and use git describe
2024-06-13 11:20:46 Zhenech yeah, that doesn't sound crazy
2024-06-13 11:21:08 bastelfreak :(
2024-06-13 11:21:16 * bastelfreak likes the crazy ideas
2024-06-13 11:23:25 Zhenech "no, not like this"
2024-06-13 11:24:52 ewoud question is: do you modify the git checkout, somehow enhance puppet-modulebuilder to be able to patch on the fly or hack the resulting tar file?
2024-06-13 11:26:42 ewoud it already stages files in a build dir, so that could work
right now people have to run the
releaserake task. That will push a tag and commit. That's bad because some people have their local repo setup in a wrong/different/odd way so the commit ends up in their fork. Also we cannot enable branch protection for master. I would like to see an optional github action that can run the rake task. and I would like to rethink the bumping to -rc0 after a release. IRC discussion: