Implement Workflow for building releases (both beta and official)

[derimmer]

@geezer09 I am ready to go with trying your workflow to build the 6.7.0-beta1 release and all the related steps.

Let me know how you want to proceed.

[geezer09]

Hey @derimmer, my workflows are pretty much ready to test for beta releases. I guess the only difference with beta is they don’t get published to the website right? I still need a bit of work to automate the website update but probably wont need that for a little while

Do we need to upload the compressed repo files to the release page? Currently I am only uploading the .vmod file. Why would anyone want the source code, and if they do they can just pull it off the repo at the tag associated with the release

[derimmer]

Hey @derimmer, my workflows are pretty much ready to test for beta releases. I guess the only difference with beta is they don’t get published to the website right? I still need a bit of work to automate the website update but probably wont need that for a little while

Correct on both counts

Do we need to upload the compressed repo files to the release page? Currently I am only uploading the .vmod file. Why would anyone want the source code, and if they do they can just pull it off the repo at the tag associated with the release No, I have never uploaded the compressed repo files. Github seems to do that all by itself.

Feel free to go ahead and trigger the release.

Then show me how you do it. Thanks.

[geezer09]

Okay I ran the workflow and it seem to work for the most parts, still needs some tweaking but getting there. I left the release as a draft, if you want to have a quick look at the release notes and and then you can publish if you are happy with it.

Here is a brief description of how the workflow operates. There are alot of little check and steps that will probably need to be fine tuned and changed but right now here is what is going on under the hood. As you might have seen I have taken the master branch and renamed it to production, the idea is that every single commit to production will produce a new release, this will give us a clear time line of what happened from release to release and will help us when debugging. This will not be 100% true at the start because I will have to make plenty of little of adjustments to the workflow files, which will produce commits without new versions, but we'll get there.

In order to push a commit to production, the proper way of doing that if from the develop branch. Pull any work done since last release into develop, then create a temporary branch called (for example) release 6.7.5. This branch is not used to do any "useful work" your just preparing it to merge into production, this means you are updating the new release-notes.md file i have place in the dist folder to include all relevant documentation for this new release (bug fixes, new features, etc). You also need to upload the new version of the anticipated release in the pom.xml file.

Once this is done and you are ready to merge, you create a pull request from your temporary branch (release 6.7.5) to production. This will start a series of "pre-test" to make sure you are indeed ready to release a new version. If you look in the .github/workflow folder you will see the three workflow files responsible for all of the automation. PR_check runs when a pull request is triggered and you can take a a look to see what it checks for but basically it makes sure you incremented the version properly, does a test build to make sure the maven package command dosent produce any errors and runs the new script i wrote to check to make sure that map versions match.

In this pull request, if any of the test fails, look at the output and fix them until all test pass. At that point, merge your pull request and then the create_release workflow triggers. If everything works well, this will create a new release with the proper version number, upload the .vmod file to the release and display the release-notes.md to the release page.

The last step is to update the website, im currenlty running into a few problems there but shold have it all sorted out well before we need to update the website. If the version you selected has "beta" in it, then this step is automatically skipped anyways.

After the release is produced, a post to BGG and wherever else you desire is all that should be required. I also recommend pulling in any changes from production into develop and then starting all over by branching from develop for the next iteration. Ideally when you start a new iteration you should only have two or three branches. Production, develop and devx.y.z or something like that.

At this point I have kept the publication of the release in draft form so that modifications can easily be made to it and manual approval of the website update will be required until we iron out the kinks and can let 'er rip. Once we do make things run smoother. ill create a document in the repo to outline these steps and any additional ones we deem necessary.

Hope this helps and don't hesitate if you have any questions or comments.

[derimmer]

. . . does a test build to make sure the maven package command dosent produce any errors . . .

So, we continue, at some point to use the "mvnw" command to compile the .vmod?

After the release is produced, a post to BGG and wherever else you desire is all that should be required. I also recommend pulling in any changes from production into develop and then starting all over by branching from develop for the next iteration. Ideally when you start a new iteration you should only have two or three branches. Production, develop and devx.y.z or something like that.

Can we automate branch descruction as part of the above? I think one of our issues is stale branches hanging around forever. I agree with the goal of starting from as clean a sheet as possible after each release: (1) reset develop from production, (2) delete all branches that do not have commits that are not in develop - or maybe there is a better test?

At this point I have kept the publication of the release in draft form so that modifications can easily be made to it and manual approval of the website update will be required until we iron out the kinks and can let 'er rip. Once we do make things run smoother. ill create a document in the repo to outline these steps and any additional ones we deem necessary.

Hope this helps and don't hesitate if you have any questions or comments.

This is excellent as far as I am concerned.

[derimmer]

I see you have published the release. Really like the presentation! Big improvement.

I will post on FB and Discord.

I will update the VASL Coop page on VASL.info

[derimmer]

I downloaded and started the beta1.vmod. All worked as expected.

I did note that the What's New file was not updated inside the beta1. That's a step we will need to integrate in the next iteration. In my view, the workflow should check that the What's New file has been updated since the previous release. If not, it should trigger an error. Would it be possible to have the release-notes.md turned into a pdf by the workflow? I have no concern about preserving the current format of the What's New document - I kind of like your format better.

[geezer09]

Yeah i’ve been working on that issue. The pdf file format is a bit unfortunate because it does not lend itself well to the ci/cd pipeline. I’ll come up with a solution shortly, i’d like the file accessible from within the game to be a bit more comprehensive then what is shown on the release page, perhaps show a history of the last few versions.

Still a work in progress.

[derimmer]

I noticed that create_release.yaml invokes mvn clean package on line 39. Recently, we have been using 'mvnw clean package' to build the module.

I have been trying to update branch feature/vasldougreg by pulling all the 'develop' changes into it. It is capturing the following problems:

There are about 20+ more files in addition to the ones above. I do not know how to resolve these errors. Advice?

[geezer09]

Noted about the mvnw command, ill update that for next release.

As for the above ‘errors’ they are just merge conflicts. This happens when you try to merge two branches where changes were made to same lines within a file. You just have to manually go through those and decide what you want to keep and what you want to throw. That tends to happen with older branches. The process is a bit confusing at first but nothing destructive is done so don’t worry too much about.

[derimmer]

I am having trouble with the "manually go through those". How do I actually do that? In all of these cases, a file needs to be deleted from the branch I am trying to pull changes INTO.

Do I close the PR, delete the files and rerun the PR? I have tried that and I can't seem to get the files to delete from within Github.

Should I be doing it another way?

Sorry to bug you with what should be a simple process.

[geezer09]

I wouldnt do this as a PR. I’m not sure exactly what your trying to do, but merge development into your feature branch locally and then intellij will help you sort out the conflicts. Once it is done in your local repo you can push that up to the remote.

[derimmer]

Duh! I have only done that about a 100 times! Why do it the easy way when there is a more complex option!

Done and dusted, I will delete the github branch.