New release workflow

[danielhollas]

I wanted to change the release workflow to the new semi-manual one that we now have in AWB (see the second commit on this PR), but then realized in in the case of QeApp, we don't really need a GHA workflow for it, because the release is just the tag on the main branch!

@unkcpz I thought it would be nice to merge this and test by releasing the alpha version that should support aiida-core~=2.5.

Also added a Dependabot config, same as in other repos.

(NOTE: Sorry I didn't write up the new workflow on the wiki yet, I'm hoping to do that today)

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 75.85%. Comparing base (f63da7d) to head (18e9dff).
Report is 62 commits behind head on main.

❗ Current head 18e9dff differs from pull request most recent head e635b5c. Consider uploading reports for the commit e635b5c to get more accurate results

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #636      +/-   ##
==========================================
- Coverage   80.73%   75.85%   -4.88%     
==========================================
  Files          49       60      +11     
  Lines        3415     4312     +897     
==========================================
+ Hits         2757     3271     +514     
- Misses        658     1041     +383     

Flag	Coverage Δ
python-3.10	75.85% <ø> (-4.88%)	⬇️
python-3.8	?
python-3.9	75.88% <ø> (-4.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.

[unkcpz]

thanks @danielhollas!
@superstar54 is ask to make a release, and since he is now take over the maintenance of QeApp, I assume he is willing to learn how to make release from reviewing this (and by try to make an alpha release).

[danielhollas]

@superstar54 I've written up a new release process in the wiki

https://github.com/aiidalab/aiidalab/wiki/Development-guide#releasing-a-new-version

Let me know if it makes sense.

[superstar54]

@danielhollas thanks for the update! I will follow the wiki and try to release a new version in the next few days.

[danielhollas]

Great. Please coordinate with @unkcpz I think we want to first release an alpha version to test compatibility with AiiDA v2.5

[unkcpz]

I think we want to first release an alpha version to test compatibility with AiiDA v2.5

Thanks both! Sure, and there are quite some issues before we move to v24.04.0, here are the milestones, we need check and estimate what we can do for the next release. The initial goal is to include all the new property plugins to this release.

[danielhollas]

@unkcpz to be honest, I would be unhappy if we blocked releasing 2.5 image on all this work since I'd really like to start using it (and it should also significantly speed the loading time of the demo server). Could you maybe backport what's needed on the support branch?

[unkcpz]

@unkcpz to be honest, I would be unhappy if we blocked releasing 2.5 image on all this work since I'd really like to start using it (and it should also significantly speed the loading time of the demo server).

There is no need to backport the test on aiidalab-docker-stack is test against the pre-release version. I also want to make the release, and he block is #601, which the test failed. @superstar54 are you able to working on #638? I am a bit packed until the end of this month.

[superstar54]

@danielhollas Suddenly, I got a message from @unkcpz saying that making a new release is an urgent thing. Since I didn't touch the release stuff before, this work is kind of "new" to me, to better understand what's going on here and what to do next, I want to ask some "naive" question.

I would be unhappy if we blocked releasing 2.5 image on all this work since I'd really like to start using it

what's "all this work", and why it blocks the releasing?

@superstar54 are you able to working on #638?

I checked the #638, maybe I missed something, I think fixing #638 will not solve #601. @unkcpz could you give more detail on what you think?

[unkcpz]

I checked the #638, maybe I missed something, I think fixing #638 will not solve #601. @unkcpz could you give more detail on what you think?

In the dependencies we put aiida-quantumespresso~=4.4 which means we can support both v4.4 (when the container has aiida-core<2.5) and we can also support v4.5 (when the container has aiida-core>=2.5). This is also what we want because we want make QeApp works on the current container deployed (in PSI, and in demo server etc. which still use aiida-core<2.5 in the foreseeable time before we are confident with aiida-core==2.5.0).

So I propose to add test to test QeApp (#638) along with both aiida-core versions to make sure we are in a safe situation. We should not just update the data regression test to pass the test because it is not valid test for the old stable version.

tl;dr, we want the next release of QeApp can be installed and work for both aiida-core==2.4 and aiida-core==2.5.

[danielhollas]

what's "all this work", and why it blocks the releasing?

Sure, and there are quite some issues before we move to v24.04.0, here are the milestones, we need check and estimate what we can do for the next release.

I guess I just misunderstood what Jusong wrote above? It gave the impression that the stable release is far away?
I didn't want to add too much pressure here, appologies. But it seems the amount of work to get a version that works with 2.5 is not that large, and since we've been working on it with @unkcpz for quite some time it would be great to finish.

[unkcpz]

I guess I just misunderstood what Jusong wrote above? It gave the impression that the stable release is far away?

You are true about it, the stable release is far away. But release of the stable version will not block keep on making apha version and thus not block the test of aiidalab-docker-stack (which test upon the pre-release as "stable" test and upon main branch as "dev" test). So what I ask @superstar54 is to find a way to on testing on both versions since he is more familiar with the failed data regression test and I don't have time to work in two weeks.

But it seems the amount of work to get a version that works with 2.5 is not that large, and since we've been working on it with @unkcpz for quite some time it would be great to finish.

I understand, I also keen to get this done. It is more or less just one step away.

[superstar54]

Hi all, @danielhollas @unkcpz thanks for details. I will work on the #638 ASAP.

[unkcpz]

Hi @danielhollas, thanks! I just did the release with Xing and realize this PR better go first. Since we already did the release PR with a branch named release/** which trigger the CI you deleted here. I'll go with that one first otherwise @superstar54 need to delete all tags and branches and do it over again.

[unkcpz]

Just realize another problem, we encourage people to not make PR from aiidalab repo but from fork, so usually the origin is set to forked repo while upstream is set to aiidalab repo. Then the default branch usually is origin and bumpver will use default branch to push.
There are two approaches to solve the issue:

1. Change the default remote by git branch --set-upstream-to upstream/main and change it back after.
2. We add a feature to bumpver to allow set the remote repo to push branch and tags.
3. We use bumpver without tag and push option, and do it manually (this is what me and @superstar54 did for this time).

@danielhollas I think make the change to bumpver tool is a better solution, what do you think?

[danielhollas]

Hmm, but we tested that when you run bumpver in a branch it pushes that branch, and not main. It shouldn't matter if you push to fork or origin, since you will merge to origin anyway. Did I misunderstood?

[unkcpz]

It shouldn't matter if you push to fork or origin

What about the tag? We need the tag appears also in aiidalab/aiidalab-qe not forked repo.

[danielhollas]

The tag should appear there once you merge, no? That's why it is important to merge, and not rebase or squash merge, since the tag is always tied to the commit.

[unkcpz]

That is not true I think, only if we have a CI action to do it for us explicitly. The tag always need to be created locally and push to remote repo I think, and in the past bumpver manage this for us.

[danielhollas]

Seems like we talk past each other a bit. Yes, tag is created locally via bumpver and pushed to the repo. But the tag is not a separate entity, it always belong to a commit. So if you merge a branch from a forked repo, you'll get the tag together with the merged commit.

[unkcpz]

Yes, I remember, but that because the tag is created in the origin repo, it point to the commit.

But the tag is not a separate entity, it always belong to a commit.

Maybe I am wrong, but this not happened to @superstar54's case after we get the PR merged. You can try it with QeApp, we can delete it after. You can try by change the default remote branch to your forked repo first by git branch --set-upstream-to <forked>/main and run bumpver.

[danielhollas]

I'll take a look and test it, perhaps I am wrong and Github does something different.

[superstar54]

Hi @danielhollas , I merged this PR first. Then try to make a new pre-release, and test it in the new docker aiidalab/aiidalab-docker-stack#424

[danielhollas]

@superstar54 please take a look at the expanded guide that I wrote and let me know if anything isn't clear, thanks!

https://github.com/aiidalab/aiidalab/wiki/Development-guide#releasing-a-new-version

[superstar54]

Thanks @danielhollas !