twine's --skip-existing is not a client-side flag: it asks the repository
whether it supports the feature, and Gitea's PyPI registry does not advertise
it, so the upload fails with UnsupportedConfiguration before it starts. Check
the simple index for the version instead -- the same check-then-publish shape
the npm step already uses.
With PACKAGES_TOKEN in place, npm and PyPI published 0.2.0 and NuGet failed:
error NU5026: The file '.../bin/Release/net6.0/Maxvojtkov.Dokploy.dll'
to be packed was not found on disk.
The generated csproj sets GeneratePackageOnBuild, and `dotnet pack` on such a
project skips compiling -- it assumes the build already packed -- so it packs
an assembly nothing ever built. Pack with the property turned off and it builds
the project itself.
That left the release half-published again, and re-running it would have
stopped at the first registry that already had 0.2.0: Gitea answers a repeat
publish with 409, which npm and the Go upload both treat as fatal. Every
publish step is now idempotent -- npm checks first, twine takes
--skip-existing, the Go upload accepts 409, and NuGet already had
--skip-duplicate -- so a release that fails halfway can simply be run again.
The SDK job reached `npm publish` and got E401. The token Actions injects is
real and valid -- 40 characters, `GET /api/v1/user` returns 200, and it reads
the package registry as the repository owner -- but every *write* to the
registry is refused:
npm PUT (bearer, as npm) -> 401
npm PUT (basic) -> 401
Both schemes, so this is authority and not `_authToken` sending Bearer. Adding
`permissions: packages: write` to the workflow changed nothing either.
So the four publish steps now take PACKAGES_TOKEN, a repository secret holding
an access token scoped to `write:package`. goreleaser keeps the injected token:
it creates the release and uploads binaries, which is repository write, and
that half has always worked.
This is why v0.1.0's packages had to be published by hand -- the SDK job has
never once run to completion.
The v0.2.0 plugin binaries published, then the SDK job died in tfgen:
panic: fatal: error An assertion has failed: bulk converting examples
failed. convertViaPulumiCLI: pulumi executable not in PATH
tfgen converts the upstream provider's documentation examples into each
language by shelling out to `pulumi convert`, and asserts rather than degrades
when the binary is missing. The build workflow installs the CLI; this job never
did. It went unnoticed through v0.1.0 because tfgen had no docs to convert
until UpstreamRepoPath pointed it at the upstream checkout.
So half a release is published and the other half is not, and re-pushing the
tag would rerun a 45 minute build against artifacts that are already uploaded.
Let a dispatch republish just the SDKs instead: it takes the tag to publish,
skips the plugin job, and checks the tree out at that tag while the workflow
file itself comes from the branch it was dispatched on.
The v0.2.0 release died twice on the runner -- once OOM-killed by six parallel
builds, once with the host going away mid-compile -- and each time the only way
back was to delete the tag and push it again. That is destructive, it rewrites
published history for a version that may already be half-published, and it is
easy to get wrong under pressure.
Add a workflow_dispatch trigger so the same release can simply be re-run.
goreleaser refuses to release from an untagged commit, so a dispatch can only
ever republish a real tag.
The sdks job derived VERSION from the ref name, which is the tag on a push but
the branch on a dispatch. It now asks git which tag the checked-out commit
carries, with --exact-match so an untagged commit fails loudly instead of
publishing under the previous version. That needs the tags, hence fetch-depth.
The v0.2.0 plugin release ran for 31 minutes and then died:
build failed: exit status 1:
github.com/pulumi/pulumi/sdk/v3/go/pulumi:
compile: signal: killed
target=darwin_amd64_v1
`signal: killed` is the OOM killer. A bridged provider links the entire
Terraform provider and the Pulumi SDK into a single ~100MB binary, and
goreleaser defaults its parallelism to the CPU count, so several of those
compiles were resident at once on a runner that could not hold them.
Serialise the builds and lower the compiler's GC target. Slower in wall-clock,
but it is the difference between a release that finishes and one that does
not.
The build job regenerates schema.json and diffs it against the checked-in
copy, to catch a resources.go edit that never got a `make tfgen`. The comment
above it claimed the schema carries no version. It does: tfgen writes the
upstream version into `packageDescription`.
So the job, which builds at the Makefile's default VERSION, regenerated a
schema stamped v0.1.0 and diffed it against the committed v0.2.0 one. The
v0.2.0 push failed on a mismatch that had nothing to do with the mapping.
Bump the default to match the committed schema and say plainly in both places
that the two move together. Verified by running the job's exact command --
`make provider` with no override, then the diff -- which now exits 0.
The release job was unaffected: it derives VERSION from the tag.
Six new resources from terraform-provider-dokploy v0.2.0 -- Network,
DnsProvider, VaultProvider, Schedule, VolumeBackup and Libsql -- plus the new
properties on Domain (`enabled`), Compose (`serviceNetworks`, `createEnvFile`,
`icon`) and Application. Verified with `pulumi up` against a live v0.30.2
instance: create, preview-clean, and destroy.
The upstream provider also now refuses a volume Mount with no `volumeName`,
which Dokploy would otherwise turn into an anonymous Docker volume recreated
on every deploy. That surfaces here at preview time, before anything exists.
Two things made that fix nearly invisible to Pulumi users, so this commit
fixes the second one: the bridge resolves the upstream `docs/` through the Go
module cache, where a locally `replace`d dependency never lands, so tfgen was
emitting every resource with no description at all. UpstreamRepoPath now
points at the checkout and all 445 inputs carry documentation -- with names
rendered per language, so Python readers see `volume_name` where TypeScript
readers see `volumeName`.
max-voitcov