Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Create upversioning utility to upgrade schema and test messages version #477

Merged
merged 31 commits into from
Oct 27, 2022

Conversation

noursaidi
Copy link
Collaborator

@noursaidi noursaidi commented Oct 6, 2022

A tool to change the version in test messages/examples.

Introduces the $id annotation into schema files, and uses it so schema files are tagged with the version.

Uses a combination of a list of files to upgrade and a list of files to ignore, so any new files must explicitly be added into either at the time of running the utility.

Usage: bin/upversion NEW_VERSION

@noursaidi
Copy link
Collaborator Author

I'll need to do something about schema/categories.json which is automatically generated

@noursaidi noursaidi changed the title Create upversioning utility and upgrade schema/test messages to 1.4.1 Create upversioning utility to upgrade schema and test messages version Oct 6, 2022
Copy link
Collaborator

@grafnu grafnu left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Mainly not sure about the $id field -- something about that doesn't smell right... what's it for? Why is it called "$id"?

bin/upversion Outdated
echo Done!\n

echo Commit changes with:
echo "git add tests/*.tests/*.json"
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not a big fan of holding people's hands through all this -- I wouldn't explicitly enumerate all the steps. They should be clear enough. You run the tool, and then there are changed files. There's nothing about this process that's specific to this. So, this should be in documentation on "how to upgrade version" not as output from the tool...

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Originally did the tool did the tag and commit, but I ran into X reasons why that was a terrible idea so turned into echo. But they're removed now

@@ -0,0 +1,69 @@

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

extra blank line?

@@ -1,4 +1,5 @@
{
"$id": "https://raw.githubusercontent.com/faucetsdn/udmi/1.4.0/schema/configuration_endpoint.json",
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What's the $id line mean? This doesn't smell right to me...

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As per discussion below changed to $udmi_version

bin/upversion Outdated
exit 1
fi

# Check all files are included in EITHER the yay list or nay list
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we'd also need/want to find a way to detect entries that are in the list but aren't actual files -- otherwise there's potentially going to be a lot of garbage in there!

@@ -0,0 +1,25 @@
tests/event_discovery.tests/empty.json
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Consider just one file with a meaningful prefix? Like:

y tests/event_system.tests/empty.json
n tests/config.tests/empty.json

Leaves room for future expansions too, if necessary/

And # headers would be very useful to annotate, if necessary.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Comment incorporated

bin/upversion Outdated
@@ -0,0 +1,92 @@
#!/bin/bash
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

generally add -e flag unless there's a specific reason not to.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added -e

@noursaidi
Copy link
Collaborator Author

@grafnu re the $id field I took it from JSON Schema docs as the closest thing to a "version" attribute which it lacks.

We could just add our own, either $version or $UDMI, with just the value being just the version (e.g. 1.4.0)

@grafnu
Copy link
Collaborator

grafnu commented Oct 10, 2022 via email

@noursaidi
Copy link
Collaborator Author

The intention behind the addition was to have some reference of the version of UDMI (e.g. 1.4.0) when looking at the schema, because without doing anything git related, it's not possible to tell which version it relates to. This is trying to address some issues people have had.

Removing the semantic information from the value of $id, it would no longer meet this specific purpose.

@grafnu
Copy link
Collaborator

grafnu commented Oct 11, 2022 via email

@noursaidi noursaidi marked this pull request as ready for review October 26, 2022 15:13
@noursaidi noursaidi requested a review from grafnu October 26, 2022 15:13
@noursaidi
Copy link
Collaborator Author

CI Run here

I can split the tool and the upversion to 1.4.0, but thought to leave it as an example of what exactly it does

bin/upversion Outdated
TESTS_REGEX="^(\s{0,4}\"version\"\s*:\s*)([0-9.\"]*)(,?)"
SCHEMA_VERSION_IDENTIFIER=\$udmi_version # must start with $

# Updates existing $udmi_version in a JSON file. Called by
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

NB: Typically avoid "called by" comments because all they do is get out of date and become inaccurate. It's easy enough to search for "update_existing_schema_version" so it's not hard to find where it's used...

bin/upversion Outdated
}

# Updates an existing $udmi_version, or adds if missing
# Usage: update_schema_version FILE_TO_UPDATE NEW_VERSIO
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Missing trailing N

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

added

bin/upversion Outdated

if ! [[ $NEW_VERSION =~ ^[0-9]+\.[0-9]+\.[0-9]+$ ]]; then
echo ERROR Invalid version: $NEW_VERSION
# exit 1
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Remove comments for dead code. In the long run "# exit 1" isn't useful for anything...

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

all the exit 1 shouldn't have been commented, they have been uncommented


bin/check_version
if [[ -n $(git tag -l $NEW_VERSION) ]]; then
echo ERROR New version $NEW_VERSION already exists in upstream repo.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if the system keeps going not sure these count as errors... so, either WARNINGS, or it should fail on these conditions... ?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The exit 1 shouldn't have been commented out, so it should fail at each stage.

bin/upversion Outdated

if [[ -n $err_upversion_list ]]; then
echo ERROR .. above files not found in upversion list or listed more than once
# exit 1
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what you can do is "touch .has_an_error" or something as a marker, and then at the end of the bunch of code, you just have one place that exits if that file exists. (You can also just set a bash variable as long as you're careful of subshell scoping.)

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good suggestion, incorporated this for the errors which aren't for a duplicate version or unclean git

# - specific java files (Pubber.java, ConfigUtil.java, LocalDevice.java)

UPVERSION_LIST=etc/upversion.txt
TESTS_REGEX="^(\s{0,4}\"version\"\s*:\s*)([0-9.\"]*)(,?)"
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can you use jq instead of this? Seems very unstable... e.g. you can set a value with something like (from elsewhere in scripts):

bin/reset_config: jq .system.testing.sequence_name="${config_file%.json}" > ${dst_config}

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tried jq but opted for sed because:

  • For files in test/*, jq does not support comments, so cannot be used for these files.
  • For files in schema/* jq
    • adding a field puts it at the bottom, whereas it makes more sense for this to be at the top
    • reformats (although very little) content, namely enforces one item per line in lists.
      For all changes, there are checks that there is one of whatever it is expecting to replace for sanity

n tests/envelope.tests/gateway.json
n tests/envelope.tests/example2.json
n tests/envelope.tests/errors1.json
n tests/state.tests/makemodel_upgrade.json #tests message upgrade from v 1
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

space after #

Is the # even necessary, or just convenience? What happens if there's other words after the file... ? Seems like having the # is better overall, just kinda curious... ?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Used it to improve readability, but is not necessary, passed through bash read action file comment so everything after the second space is a comment

@noursaidi noursaidi requested a review from grafnu October 26, 2022 17:43
@noursaidi noursaidi merged commit 7755958 into faucetsdn:master Oct 27, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants