@benjamb I think an update to semantic-release might have made a change in its behavior and it's trying to push via the job token rather than the PAT. I'd have to take a closer look later though
Thanks a lot @antoineOG
I think this makes sense even if it only cleans up a few lines of code - still better than chasing down edge cases when using custom code.
Thanks for the write-up @antoineOG
To be honest, on a long term basis, I think things like this should be done using a library like https://pypi.org/project/pkginfo or similar, if it turns out to be more reliable. There are a lot of edge cases that a self-built helper will not catch, especially coming up in larger migrations.
I saw a similar error with NPM package metadata that I haven't had time to pinpoint, but it points to a more general issue with package migrations. I think metadata extraction needs to be a bit more relaxed because people do strange things with their packages sometimes - if the package format allows it, Congregate should too
Nejc Habjan (3dd2b2ad) at 27 Jan 22:47
At present there are various conditionals in the code base that check the GitLab version and handle any discrepancies in the API between these versions. This currently includes checks for 9.2.2, 9.2.3, 10.5.0, 11.2.
While I think it's a good idea to support the latest and the previous major version of GitLab, I think we should aim to remove dead code to handle versions no longer supported by GitLab upstream.
Nejc Habjan (9eecd74c) at 27 Jan 22:47
Merge branch 'benbrown/compatibility' into 'main'
... and 2 more commits
Additionally align the automated release process with this policy, i.e. breaking changes result in major releases.
Closes #404.
Makes total sense, and this one completely slipped, my bad!
Nejc Habjan (3dd2b2ad) at 27 Jan 22:45
chore: Explicitly apply conventional commits preset to commit-analyzer
... and 9 more commits
Additionally align the automated release process with this policy, i.e. breaking changes result in major releases.
Closes #404.
Hey @benjamb, you were faster before I could reply. Added you as owner and added the new token as you've probably noticed. We should probably auto-rotate that, I'm sure I've rambled about that before.
Edit: and still busy with other stuff in life/work so not doing a great job here
There is a maintained community fork of kaniko: https://github.com/osscontainertools/kaniko (disclaimer: I'm also now involved over there).
You can use it as ghcr.io/osscontainertools/kaniko:v1.26.3-debug for example.
We've switched to this in my org, and also have a renovate replacement preset for it to automate migrations.
{
"description": "Replace unmaintainted kaniko image with community fork",
"matchPackageNames": ["gcr.io/kaniko-project/executor"],
"replacementName": "ghcr.io/osscontainertools/kaniko"
}