Most recent artifacts

[tghosth]

I like the fact that the new automation only builds the updated documents if something in that location has changed.

However, it then makes it trickier to find the latest artifacts. E.g. how do I find the most recent 4.0 artifacts?

Any thoughts?

One option is to change the build task to run once a day on all 3 builds but that seems a little blunt, is there an easier way to achieve this @ike ?

[ike]

Yeah, I've considered this a bit, and I'm torn: on the one hand, artifacts are an ephemeral, point-in-time build that doesn't produce any commits, on the other hand, they're hard to find and relate to the state of the repo.

Another option is to commit the built files to the pull request. The builds would appear in the pull request along with any source changes, as an automated commit. The action would still only build if the relevant source had changed. I'd be curious of your thoughts on this approach.

There are probably other considerations here, like cutting versioned dev releases after merges to master, etc. There's lots of flexibility, we just need to find an approach that works well with the team's workflow.

[tghosth]

let's leave it for now. I think we need to think about this more.

[ike]

Agreed, sounds good to me.

[ike]

I suggest two types of releases to fix this issue, and to help automate releases in general:

• a latest release that would overwrite itself on each push to master. This release would include the artifacts for all versions of the standard, and would be the place to look for the "most recent" artifacts for any given version of the standard.
• an automatic versioned release that is cut whenever a new tag is created. This release would include the artifacts for whichever major version the release refers to, i.e. creating a tag called 5.1.2 would build the artifacts for the 5.0 directory based on the tagged commit and add those artifacts to the release.

This would solve the problem of not knowing where the "most recent" artifacts were, as well as providing a simple way to release a new version. This approach would avoid a) messy automated commits to master, and b) creating a dev release for every commit to master.

To facilitate this, we could use a github action such as Automatic Releases.

[tghosth]

Could you try and prepare something like this @ike?

Thanks!

[ike]

Absolutely. I'll get to work on this.

[tghosth]

Hi @ike, any update on this?

[ike]

I finally found some more time to do this work -- I am hoping to have a proof-of-concept soon.

[tghosth]

Hey @ike! Good to see you back!

Let me know how it goes :)