Skip to content
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

Merged
merged 2 commits into from
Feb 12, 2021
Merged

Conversation

glensc
Copy link
Contributor

@glensc glensc commented Jan 25, 2021

Use https://github.com/laminas/automatic-releases project for automating releases.

@glensc glensc self-assigned this Jan 25, 2021
@glensc
Copy link
Contributor Author

glensc commented Jan 25, 2021

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 master).

As the workflows are loaded from the default branch? Perhaps should edit the default branch to be this PR's branch (releases) and close 0.18.1 milestone?

Also, as we don't maintain changelog, just drop "Bump Changelog Version On Originating Release Branch" step?

@glensc
Copy link
Contributor Author

glensc commented Jan 25, 2021

@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.

@Ocramius
Copy link

Also, as we don't maintain changelog, just drop "Bump Changelog Version On Originating Release Branch" step?

If CHANGELOG.md is missing, this step will ignore everything anyway.

@Ocramius
Copy link

Ok, so here's what I suggest to do with the migration

  1. merge this
  2. git checkout master && git checkout -b 0.18.x && git push origin 0.18.x (assuming master is where you were starting from)
  3. set 0.18.x as default branch
  4. close the 0.18.1 milestone
  5. profit?
  6. delete master if no PRs reference it

In theory, that should be it 👍

@glensc
Copy link
Contributor Author

glensc commented Jan 25, 2021

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:

  1. set project default branch to releases (this PR branch)
  2. create base branch 0.18.x: g co -b 0.18.x releases && g push origin 0.18.x
  3. set 0.18.x as default branch
  4. close the 0.18.1 milestone
  5. evaluate what's happening

I guess I can skip the "1", as it is changed immediately in step "3".

if everything fine:

  1. re-open 0.18.1 milestone
  2. merge this to master
  3. re-create 0.18.x branch from master
  4. delete master branch
  5. close 0.18.1 milestone

@Ocramius
Copy link

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.

@glensc
Copy link
Contributor Author

glensc commented Jan 25, 2021

@Ocramius I do not wish to merge broken things to master, broken as in end up needing to force push master to remove commits from it. Does the test scenario I proposed works in your opinion or you see something flawed with the plan?

@Ocramius
Copy link

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 :-)

@glensc
Copy link
Contributor Author

glensc commented Jan 25, 2021

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.

@glensc
Copy link
Contributor Author

glensc commented Jan 25, 2021

progress

based on plan:

steps:

  1. created branch 0.18.x from branch releases
  2. closed milestone 0.18.1
  3. ci was fired: https://github.com/perftools/xhgui/actions/runs/509960703
  4. ... TBD

@Ocramius
Copy link

gpg: key 6F24A37776F19077: public key "Elan Ruusam�e <***>" imported
gpg: key 6F24A37776F19077/07E7C6216CD334B4: error sending to agent: Inappropriate ioctl for device
gpg: error reading '/tmp/imported-keyDQ3uYh': Inappropriate ioctl for device
gpg: import from '/tmp/imported-keyDQ3uYh' failed: Inappropriate ioctl for device

Seems to indicate that it tried to open TTY0, probably to ask for a password. Is the configured private key password-less?

@glensc
Copy link
Contributor Author

glensc commented Jan 25, 2021

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.

@Ocramius
Copy link

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 :-\

@glensc
Copy link
Contributor Author

glensc commented Jan 25, 2021

@Ocramius I think it may be related to the last step in readme which I did not understand and so nothing was done:

Then republish it to anywhere that you currently publish your public keys.

Here's local tester, using the file that was inserted as SIGNING_SECRET_KEY, just re-exported it

$ gpg --homedir gpg-tmp --output private-$(curdate).key --armor --export-secret-subkeys "07E7C6216CD334B4!"
➔ gpg --homedir=tmp2 '--import' private-20210125.key
gpg: keyblock resource '/Users/glen/scm/php/automatic-releases/tmp2/pubring.kbx': No such file or directory
gpg: no writable keyring found: Not found
gpg: key 6F24A37776F19077: failed to re-lookup public key: No public key
gpg: error reading 'private-20210125.key': No public key
gpg: import from 'private-20210125.key' failed: No public key
gpg: Total number processed: 0
gpg:       secret keys read: 1

gives me an indication that something related to public key is incomplete.

@glensc
Copy link
Contributor Author

glensc commented Jan 25, 2021

nevermind last comment, lack of homedir was the error source

[~/scm/php/automatic-releases (patch-3)★] ➔ mkdir tmp2

[~/scm/php/automatic-releases (patch-3)★] ➔ gpg --homedir=tmp2 --list-keys
gpg: WARNING: unsafe permissions on homedir '/Users/glen/scm/php/automatic-releases/tmp2'
gpg: keybox '/Users/glen/scm/php/automatic-releases/tmp2/pubring.kbx' created
gpg: /Users/glen/scm/php/automatic-releases/tmp2/trustdb.gpg: trustdb created

[~/scm/php/automatic-releases (patch-3)★] ➔ gpg --homedir=tmp2 --list-keys
gpg: WARNING: unsafe permissions on homedir '/Users/glen/scm/php/automatic-releases/tmp2'

[~/scm/php/automatic-releases (patch-3)★] ➔ gpg --homedir=tmp2 '--import' private-20210125.key
gpg: WARNING: unsafe permissions on homedir '/Users/glen/scm/php/automatic-releases/tmp2'
gpg: key 6F24A37776F19077: public key "Elan Ruusamäe <[email protected]>" imported
gpg: To migrate 'secring.gpg', with each smartcard, run: gpg --card-status
gpg: key 6F24A37776F19077: secret key imported
gpg: Total number processed: 1
gpg:               imported: 1
gpg:       secret keys read: 1
gpg:   secret keys imported: 1
[~/scm/php/automatic-releases (patch-3)★] ➔

@glensc
Copy link
Contributor Author

glensc commented Jan 25, 2021

Seems there's no way to retry jobs from GitHub events:

PHP Fatal error:  Uncaught InvalidArgumentException: Could not find a value for environment variable "GITHUB_TOKEN" in /app/vendor/webmozart/assert/src/Assert.php:2042
Stack trace:
#0 /app/vendor/webmozart/assert/src/Assert.php(779): Webmozart\Assert\Assert::reportInvalidArgument()
#1 /app/vendor/webmozart/assert/src/Assert.php(69): Webmozart\Assert\Assert::notEq()
#2 /app/src/Environment/EnvironmentVariables.php(102): Webmozart\Assert\Assert::stringNotEmpty()
#3 /app/src/Environment/EnvironmentVariables.php(84): Laminas\AutomaticReleases\Environment\EnvironmentVariables::getenv()
#4 /app/bin/console.php(62): Laminas\AutomaticReleases\Environment\EnvironmentVariables::fromEnvironment()
#5 /app/bin/console.php(170): Laminas\AutomaticReleases\WebApplication\{closure}()
#6 {main}
  thrown in /app/vendor/webmozart/assert/src/Assert.php on line 2042

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)

@glensc
Copy link
Contributor Author

glensc commented Jan 25, 2021

Actually, as I'm not having any changelog, all needed steps were performed:

tag 0.18.1
Tagger: Elan Ruusamäe <[email protected]>
Date:   Mon Jan 25 17:53:40 2021 +0000

### Release Notes for [0.18.1](https://github.com/perftools/xhgui/milestone/12)

### 0.18.1

- Total issues resolved: **0**
- Total pull requests resolved: **1**
- Total contributors: **1**

 - [413: Restore flash messages](https://github.com/perftools/xhgui/pull/413) thanks to @glensc
-----BEGIN PGP SIGNATURE-----

iQGzBAABCgAdFiEEfk0uM8rm900565mcB+fGIWzTNLQFAmAPBaQACgkQB+fGIWzT
NLRZGwwAlsTaAmxDvwF7p4b2XZC2xjrXdEiGh9K7KOzv/3tdYgdQS7FgS56sPdiS
and+a6b3Qjw0ND9We6EvA7Uks1mgLH5lgPwS04hD+wxE7jxSCvNzJOeKb9wASlMB
BbYJCthWDqt45cXsHxlB7nObgpev7YS832g5duBVcbW7uXMemtUq+J+qLEN7nyb6
JdIgBVbvV5FHRDRyxkDrzwBiQDi2a4K6QQvFjVAR0JemiBmpFVXiCzduJ875Xhr1
kgg5d9u0rQ6i89CWtuX1fCNrtuXfKaU/WhGfvlPb1LfMGChKqXrVTSW+icKdfp13
OWIOmGyvHa8AlTeSszXpFaz7UV+uOnV6s3C8Au6fLS4eWBFeec3A/8bRv0v99DrI
8NdF3wROfHZjBDNoqsQ3tjs+Glhp0zYaoQyxVPtIxyuQ1Ct8W1SN4bu41t35JXev
ZkNmFmlpmi4fcuvnxDMfMEbimr61/XMlPDFx5He+JgV/07vPnMAKJorNxLCD5PqO
4o3S0aVd
=+1S+
-----END PGP SIGNATURE-----

image

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?

Docker build failed with exit code 21, back off 7.545 seconds before retry. | GIT tag, release & create merge-up PR: .github#L1
-- | --
Docker build failed with exit code 21, back off 8.692 seconds before retry. | GIT tag, release & create merge-up PR: .github#L1
Ubuntu-latest workflows will use Ubuntu-20.04 soon. For more details, see https://github.com/actions/virtual-environments/issues/1816

the first run of job seems missing, i did not save the link and can't find it in navigation.

@Ocramius
Copy link

back-off seems to be a github internal detail.

Seems there's no way to retry jobs from GitHub events:

I generally re-open the milestone and close it again: suffices to produce a new event, and therefore run.

so I'm confused about what did actually happen and what actually failed.

The GPG signature seems valid, but you probably need to replace your GPG public key on github with one that includes your new subkey.

@glensc
Copy link
Contributor Author

glensc commented Jan 26, 2021

back-off seems to be a github internal detail.

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)

@glensc
Copy link
Contributor Author

glensc commented Jan 26, 2021

trying again:

  1. deleted tag 0.18.1
  2. deleted (now draft) release for 0.18.1
  3. reopened and closed 0.18.1 milestone
  4. pipeline created: https://github.com/perftools/xhgui/actions/runs/511615326

@glensc
Copy link
Contributor Author

glensc commented Jan 26, 2021

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:

image

PHP Fatal error:  Uncaught InvalidArgumentException: Could not find a value for environment variable "GITHUB_TOKEN" in /app/vendor/webmozart/assert/src/Assert.php:2042
Stack trace:
#0 /app/vendor/webmozart/assert/src/Assert.php(779): Webmozart\Assert\Assert::reportInvalidArgument()
#1 /app/vendor/webmozart/assert/src/Assert.php(69): Webmozart\Assert\Assert::notEq()
#2 /app/src/Environment/EnvironmentVariables.php(102): Webmozart\Assert\Assert::stringNotEmpty()
#3 /app/src/Environment/EnvironmentVariables.php(84): Laminas\AutomaticReleases\Environment\EnvironmentVariables::getenv()
#4 /app/bin/console.php(62): Laminas\AutomaticReleases\Environment\EnvironmentVariables::fromEnvironment()
#5 /app/bin/console.php(170): Laminas\AutomaticReleases\WebApplication\{closure}()
#6 {main}
  thrown in /app/vendor/webmozart/assert/src/Assert.php on line 2042

But wasn't GITHUB_TOKEN automatic?

how can it go missing?

@glensc
Copy link
Contributor Author

glensc commented Jan 26, 2021

I think this is the problem, the workflow config is using org token, but I decided not to use org-wide integration:

@glensc
Copy link
Contributor Author

glensc commented Feb 5, 2021

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?

@glensc
Copy link
Contributor Author

glensc commented Feb 8, 2021

@Ocramius can you guess why it failed now?

@glensc
Copy link
Contributor Author

glensc commented Feb 12, 2021

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:

@glensc glensc marked this pull request as ready for review February 12, 2021 12:14
@glensc glensc merged commit 552d0e6 into master Feb 12, 2021
@glensc glensc deleted the releases branch February 12, 2021 12:20
@glensc
Copy link
Contributor Author

glensc commented Feb 12, 2021

Stupid GitHub, it closed all PR that target branch was master once I deleted master branch:

Including in forks and fork of forks:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants