-
Notifications
You must be signed in to change notification settings - Fork 342
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
Add release automation using laminas/automatic-release #415
Conversation
Currently, 0.18.0 was recently released, and 1 PR merged for 0.18.1: #413 The plan is to release 0.18.1 using this automation. It's unclear how to test this before merging to the default branch (currently As the workflows are loaded from the default branch? Perhaps should edit the default branch to be this PR's branch ( Also, as we don't maintain changelog, just drop "Bump Changelog Version On Originating Release Branch" step? |
@Ocramius what do you think of this plan: as I'd avoid merging things that are not even tested and current docs offer no hints on how to test or debug. |
If |
Ok, so here's what I suggest to do with the migration
In theory, that should be it 👍 |
I was hoping to get away with testing this before the merge. I.e assuming the workflows get activated if they are present in the default branch, i.e at the time of milestone close, the workflow file must be present on the default branch, so:
I guess I can skip the "1", as it is changed immediately in step "3". if everything fine:
|
The worst that can happen with this tool is publishing an erroneous tag: it does not force-push things, nor overwrites anything else, so I suggest rolling with it. |
@Ocramius I do not wish to merge broken things to |
I mean, I've done the same process described at #415 (comment) with multiple dozen repositories. The upstream tool is tested at the best of my abilities and available time, but it's obviously under MIT/BSD license If you need some sort of "dry-run" mode, that would need to be built in upstream, perhaps even with an auto-installation thingy. I've stated the risks: now it's up to you to decide whether to merge or not, but the tool will push tags, create branches, and switch default branches :-) |
I believe you had great success, and I'm not afraid tool doing something bad, but rather my setup being incomplete. Seems I'm on my own here, as you just don't want to answer. |
progressbased on plan: steps:
|
Seems to indicate that it tried to open TTY0, probably to ask for a password. Is the configured private key password-less? |
It seems to me the password is removed, I did get an error tho: If I invoke 'passwd', it will only ask new password... which's a symptom of there is no prior password. |
Perhaps @carnage can help further? I think the difference in local tooling is a bit of a barrier, and my GPG-fu isn't that strong either :-\ |
@Ocramius I think it may be related to the last step in readme which I did not understand and so nothing was done:
Here's local tester, using the file that was inserted as
gives me an indication that something related to public key is incomplete. |
nevermind last comment, lack of homedir was the error source
|
Seems there's no way to retry jobs from GitHub events:
I just picked "re-run all ci jobs", but that retry is now run without GITHUB_TOKEN Apparently, only way to retry a job is to toggle milestone state (open+close it) |
Actually, as I'm not having any changelog, all needed steps were performed:
so I'm confused about what did actually happen and what actually failed. I've closed the 0.18.1 milestone again, new CI was launched: from which I see that jobs were retried when having errors?
the first run of job seems missing, i did not save the link and can't find it in navigation. |
back-off seems to be a github internal detail.
I generally re-open the milestone and close it again: suffices to produce a new event, and therefore run.
The GPG signature seems valid, but you probably need to replace your GPG public key on github with one that includes your new subkey. |
but it's also symptom that the job was retried, as i can not find log where the tag and release were created, all i have output of failed gpg error, which right now is also unavailable as the re-run jobs made previous output unavailable (and i did not save direct link) |
trying again:
|
The missing gitlab token error persists, even for run created from close milestone event. previous assessment about retry job being of fault is invalid. it succeeded Release job which apparently created git tag and github release (no such details in it's output, but visible externally) it fails with create and/or switch release branch:
But wasn't GITHUB_TOKEN automatic? how can it go missing? |
I think this is the problem, the workflow config is using org token, but I decided not to use org-wide integration: |
Added my PAT as ORGANIZATION_ADMIN_TOKEN but "Create merge up pull request" job has failed: @Ocramius can you guide what failed now? or is there a way to enable more logging? |
@Ocramius can you guess why it failed now? |
Dunno, what failed in the previous run. I only re-run the pipeline (by deleting tag and open/close milestone) and now the pipeline succeeded without any errors: ait also created merge up pr successfully: |
Stupid GitHub, it closed all PR that target branch was Including in forks and fork of forks: |
Use https://github.com/laminas/automatic-releases project for automating releases.