Join GitHub today
GitHub is home to over 20 million developers working together to host and review code, manage projects, and build software together.
Add support for epoch property. #502
Conversation
elopio
reviewed
May 12, 2016
| + '1*', | ||
| + 1, | ||
| + '400*', | ||
| + 1234, |
elopio
May 12, 2016
•
Edited 1 time
-
elopio
May 12, 2016
Member
-
May 12, 2016
what about '00001', valid or invalid?
kyrofa
May 12, 2016
Member
Valid since YAML will parse it as 1, but difficult to test as 0001 isn't a valid number in Python.
sergiusens
May 23, 2016
Collaborator
00001 could be an integration test, but I fear we would be then testing the yaml parser instead
sergiusens
May 23, 2016
Collaborator
how about '00001'? Is that valid? I am asking without having looked at how this is spec'ed
kyrofa
May 23, 2016
Member
You mean the string "00001"? That's rejected, to avoid having to validate the number separately from the asterisk in the string. I've updated the tests quite a bit, adding both a test for 01 and "01".
|
I'm +1, with one question. Also, please update docs/snapcraft-syntax.md |
Good catch, thanks-- done. |
kyrofa
and others
added some commits
May 18, 2016
|
you can make this always a string by implementing |
I've instead updated this to validate with a custom format, where I validate via strings only and can provide a nicer-looking error message. Let me know what you think. |
sergiusens
reviewed
May 24, 2016
| + self.assertRegex( | ||
| + raised.exception.message, | ||
| + "The 'epoch' property does not match the required " | ||
| + "schema:.*is not a 'epoch' \(epochs are positive integers " |
kyrofa
May 24, 2016
Member
It's actually hard-coded in jsonschema to 'is not a'. Terrible, eh? But I wanted to use the format checkers the way they intended...
kyrofa
added some commits
May 24, 2016
kyrofa
Kyle Fazzari
|
retest this please |
|
retest this please |
|
Both tests passed, but jenkins failed to communicate the result back to github. |
elopio
merged commit a3a4728
into
snapcore:master
May 24, 2016
kyrofa
deleted the
kyrofa:feature/1581113/epoch_property
branch
May 24, 2016
pushed a commit
to kalikiana/snapcraft
that referenced
this pull request
Apr 6, 2017
kyrofa commentedMay 12, 2016
•
Edited 1 time
-
kyrofa
May 12, 2016
In order to support step upgrades, snaps need to be able to specify upgrade paths. This PR resolves LP: #1581113 by implementing that via a new "epoch" property specified in the
snap.yaml. Valid epochs are positive integers (e.g.0,1, etc.) or positive integers followed by an asterisk (e.g.1*,2*, etc.).0is epoch 0;1*is the upgrade path from 0 to 1;1is epoch 1 (and so on).