Release number on Builds

[johnml1135]

Add Serval release version number on the engine builds - so that people can see what Serval version the specific build was created with later.

[ddaspit]

I would push back on this for now until we have a better understanding of what the actual requirement is.

[johnml1135]

Agreed - this is a Serval-SF question about how to track what changes between different versions of Serval so that SF (and the users) know what the status of an actual build is including the capabilities of Serval when it was made to know if rebuilding is recommended or not.

[Enkidu93]

I would push back on this for now until we have a better understanding of what the actual requirement is.

Does this concern still stand or do we have a clearer requirement? @johnml1135

[ddaspit]

We need to talk to the SF team to find out what the exact issue is, so that we can find the best solution.

[Enkidu93]

@Nateowami What is the issue here that prompted this? Do you know? Does it still stand?

[Nateowami]

I don't know what John means by "Add Serval release version number on the build"

I just want to be able to determine what version of Serval is live, what version is on QA, and trace both to a commit in this repo.

It might already be possible to do that and I just don't know. In the Scripture Forge repo for example, you can look at the sf-live and sf-qa branches, and they will tell you what commit QA and live is at.

[Enkidu93]

I don't know what John means by "Add Serval release version number on the build"

I just want to be able to determine what version of Serval is live, what version is on QA, and trace both to a commit in this repo.

It might already be possible to do that and I just don't know. In the Scripture Forge repo for example, you can look at the sf-live and sf-qa branches, and they will tell you what commit QA and live is at.

Oh, I see. Does the /status/deployment-info endpoint meet your needs? Is it a matter of adding a link to a specific commit in that deployment info response?

[Nateowami]

Using an API endpoint like that would be very inconvenient for what I'm trying to do. Do you tag your releases in GitHub? It looks like you do for production releases, but I can't tell about QA releases. I'm pretty sure I can find the version that's on live at https://github.com/sillsdev/serval/releases, but I can't tell what's on QA.

[Enkidu93]

Oh, I see. No, the QA releases are not tagged to my knowledge. I don't see why we couldn't change our process to accommodate you. Something like releaseQA_1.4.4 (or I think John has release_1.4.QA4 in the yamls - not sure why the ordering). Is that all you'd need?

This does seem like maybe a different issue than John meant. I think he was considering putting the version number in the build data so we could retrospectively see what version of Serval a build was made under. Is there a requirement for this though?

[Enkidu93]

Oh, I see. No, the QA releases are not tagged to my knowledge. I don't see why we couldn't change our process to accommodate you. Something like releaseQA_1.4.4 (or I think John has release_1.4.QA4 in the yamls - not sure why the ordering). Is that all you'd need?

This does seem like maybe a different issue than John meant. I think he was considering putting the version number in the build data so we could retrospectively see what version of Serval a build was made under. Is there a requirement for this though?

After chatting with Damien, I think we should hold out adding the deployment info to the build until there's a well-defined requirement. But it would be easy enough to tag releases to QA. We could add status badges to the README to show what's running on QA and production that are linked to the commits.

[johnml1135]

@Enkidu93 and @Nateowami - I want to make sure that we all understand what this is about. "Serval releases" are tagged through the https://prod.serval-api.org/swagger/index.html#/Status/Status_GetDeploymentInfo endpoint. The information is defined in YAML files and is updated for both QA and production. This is about adding this "Serval release" version to the engine build metadata so that we can determine which release of Serval that a specific build was created with for logic such as "should we rebuild this engine?" etc.

[Nateowami]

@johnml1135 Understood. That could be useful. Should I create an issue for making clear what version QA is at?

[Enkidu93]

@johnml1135 Should this be postponed since there's not a definite requirement or is this something we'd like to do?

Also, it does seem like Nathaniel would like to have a straightforward way to see what version of the code is running on QA at any given time. Should we open a separate issue for this? I think using the status badges could also be a clean way to get to display that information more generally on the developer side.

[Enkidu93]

@johnml1135 Anything to follow up on here? Should we create the issue Nathaniel mentioned? Is this issue itself still a priority?

[johnml1135]

@Nateowami - you are the customer. Would you like this feature? If so, let's make sure we are building what you are wanting. Until then, let's hold off on implementing anything.

[Nateowami]

There could absolutely be value in having the version number on the build. Right now we don't have a use-case for it, but I could imagine a situation where we want to be able to detect builds created with an old version of Serval and prompt the user to regenerate them, or something like that. I don't consider it high priority though.

[ddaspit]

We can keep this open. Once SF has a specific use case and requirements, we can implement this.

[Nateowami]

I think I have just found the use-case, which is including it alongside our metrics about success and failure of builds. It would be useful to look at failures which occurred with the most recent release only.

How trivial is it to add the version to the build metadata?

[ddaspit]

Would retrieving the version number from the status/deployment-info endpoint fulfill your need?

[Enkidu93]

I think I have just found the use-case, which is including it alongside our metrics about success and failure of builds. It would be useful to look at failures which occurred with the most recent release only.

How trivial is it to add the version to the build metadata?

It wouldn't be difficult to add the version number.

Would retrieving the version number from the status/deployment-info endpoint fulfill your need?

We'll have to see what Nathaniel says, but judging from earlier conversation, I don't think this would be sufficient since he wants to see what version a build was built under (i.e., version per build, not current version per deployment) unless SF saves that version itself when the build is run, but that seems a bit janky.

[Enkidu93]

Since it looks like we now have a requirement from SF regarding adding the version number to the translation engine build, I think we can go ahead and at least do that. I'm gonna hand this off to @mudiagaobrikisil as a good first issue unless anyone objects.

[johnml1135]

This is being addressed here: #517

[Enkidu93]

Fixed here