Upgrade version of intuit/auto to use for releases to current 11.3.6, add use of "released" plugin, configure release action to act on dispatch event

[yarikoptic]

Also I removed the comment which is no longer applicable since described reasoning for some older version but did not state that we had to stick to that one

The hope is that it would help addressing some aspects (outdated pypi api usage etc) of

• Upload to pypi has failed #345

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 97.89%. Comparing base (2e6a51d) to head (30cb23a).
⚠️ Report is 3 commits behind head on master.

Additional details and impacted files

@@           Coverage Diff           @@
##           master     #346   +/-   ##
=======================================
  Coverage   97.89%   97.89%           
=======================================
  Files          18       18           
  Lines        2370     2370           
=======================================
  Hits         2320     2320           
  Misses         50       50           

Flag	Coverage Δ
unittests	97.89% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[CodyCBakerPhD]

The hope is that it would help addressing some aspects (outdated pypi api usage etc) of

IDK if it will but you can see

I have no problem using more dedicated workflows for PyPI (with on release trigger) in conjunction with auto

And the latest and greatest recommended approach requires configuring various things on the PyPI side, see #345

[candleindark]

@yarikoptic I think for the release job release.yml to actually run, we need to delete the 0.12.0 tag and 0.12.0 release in this repo as evident in rerun of https://github.com/dandi/dandi-schema/actions/runs/19543098102/

[candleindark]

@yarikoptic I think for the release job release.yml to actually run, we need to delete the 0.12.0 tag and 0.12.0 release in this repo as evident in rerun of https://github.com/dandi/dandi-schema/actions/runs/19543098102/

Additionally, I think we need to remove the c2e8ce1 commit altogether, just to be consistent.

[candleindark]

I am requesting change here to bring to the awareness of #346 (comment) which we must do for this PR to release successfully.

[yarikoptic]

@candleindark just to make sure -- why you think we can't just proceed and release 0.12.1 with the fix? as far as I can see everything else worked out besides the pypi release!

edit: although indeed it might be cleaner in longer run to just redo release fully... so I will do those deletions/reverts since it seems that dandi/schema did not get this updated schema either since it is done in the step after...

@CodyCBakerPhD

I have no problem using more dedicated workflows for PyPI (with on release trigger) in conjunction with auto

And the latest and greatest recommended approach requires configuring various things on the PyPI side, see #345

As far as we use auto, I would prefer to concentrate all release components within it to avoid duplication of some additional "dedicated workflows". Having said that, I see that in dandi-cli we have a "dedicated" custom invocation of twine in .autorc since 2021 where release workflow got actually simplified, and indeed I have missed that auto version has nothing to do with the pypi release process... so I will tune here to match closer release process of dandi-cli.

[candleindark]

@candleindark just to make sure -- why you think we can't just proceed and release 0.12.1 with the fix? as far as I can see everything else worked out besides the pypi release! moreover we did get even commit to

Sure release 0.12.1 will work. However, if you choose that route, we will need to do the following.

• Mark this one with a patch label
• Make sure the following release of dandi-archive have the dandischema dependency pinned to 0.12.1 instead of 0.12.0.
  • Add vendorization support dandi-archive#2584

Let me know which route you choose.

[yarikoptic]

ok, I think I have done all the evil needed, so we should be all set to proceed with this as minor release as prior PR had that label already.

for completeness: AFAIK there were no need to add patch here since internal would have boosted .patch component too.

My laptop burned through battery for some reason, so I need to suspend it -- if all looks kosher -- please merge. If not - please fix up and merge . I will check when I get power

[candleindark]

I don't think 30cb23a has any benefit aside from adding the released auto plugin. In fact, it brings quite a bit of redundancy since there is already the release-check job in the workflow to guard against running the release job when there is no new version, and we can't really do without the the release-check job in the current arrangement because of manual modifications of tags in

dandi-schema/.github/workflows/release.yml

Lines 119 to 134 in 30cb23a

	- name: Commit schema changes and create new tag
	run: |
	LIBRARY_VERSION="$(git -C ../dandischema describe --tags --exact-match)"
	git config --global user.email "team@dandiarchive.org"
	git config --global user.name "DANDI Bot"
	git add releases
	if ! git diff --quiet --cached
	then git commit -m "Publish model schema v$SCHEMA_VERSION as of dandischema v$LIBRARY_VERSION"
	git push
	git -C ../dandischema tag -m "Schema v$SCHEMA_VERSION, released in dandischema v$LIBRARY_VERSION" schema-$SCHEMA_VERSION
	git -C ../dandischema push --tags
	else echo "No changes to commit"
	fi
	working-directory: schema

.

Additionally, I think using a hook of auto,

dandi-schema/.autorc

Lines 8 to 11 in 30cb23a

	"exec",
	{
	"afterRelease": "python -m build && twine upload dist/*"
	}

, to run the build and upload the package to PyPi is not as good as using a step in GitHub workflow since make the step less transparent.

I suggest removing the last commit, add the released auto plugin, and consider the comment at #346.

[yarikoptic]

I would argue for the opposite that we have too much craft in ci workflow, and I do like released plug-in quite a bit, and that as long as we release with auto - we should place everything within auto so could be released outside of ci

ATM I can't discuss and since there is no consensus and since prior release attempt failed likely just due to outdated token - @candleindark please prepare minimal PR to your liking to trigger release and we will discuss these changes later.

[CodyCBakerPhD]

since there is no consensus

I am in favor of a distinct workflow to keep scopes and responsibilities cleaner.

Uploading the release to PyPI is not duplicated effort from performing a GitHub release, it is a subsequent step of a pipeline.

Same as how a conda-forge release is a distinct and separate step from the PyPI upload.

[candleindark]

@candleindark please prepare minimal PR to your liking to trigger release and we will discuss these changes later.

#348 is created. It is target to merge into this one. If you don't merge it to this one but to the master branch, make sure appropriate labels are added.

I have updated the PyPi token in this repo earlier today, so as long as the release job in release.yml is triggered, we should be good.

Once a new version is published, I will inform the archive team to pin dandischema in dandi/dandi-archive#2584 to that version.

[yarikoptic]

Work my arguments above for harmonizing and also seeing that archive also uses released plug-in, I will just proceed and we will discuss further later