search

perftools / xhgui

Web interface for XHProf profiling data can store data in MongoDB or PDO database
1.65k stars 342 forks source link

Add release automation using laminas/automatic-release #415

Closed glensc closed 3 years ago

glensc commented 3 years ago

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

glensc commented 3 years ago

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 commented 3 years ago

@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 commented 3 years ago

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 commented 3 years ago

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 :+1:

glensc commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

@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 commented 3 years ago

I mean, I've done the same process described at https://github.com/perftools/xhgui/pull/415#issuecomment-766933263 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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago 
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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

@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 commented 3 years ago

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 <glen@pld-linux.org>" 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 commented 3 years ago

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)

glensc commented 3 years ago

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

tag 0.18.1
Tagger: Elan Ruusamäe <glen@pld-linux.org>
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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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

glensc commented 3 years ago

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 commented 3 years ago

@Ocramius can you guess why it failed now?

glensc commented 3 years ago

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 commented 3 years ago

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

Including in forks and fork of forks: