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

Added the dummy buildId if not specified #110

Closed
wants to merge 1 commit into from
Closed

Conversation

EricLeiLi
Copy link

buildId is required in bar descriptor to pass build and release:
we should always generate it even the user doesn't specify it.

Fixes blackberry#211

@jeffheifetz
Copy link

Testing for this needs to cover all signing scenarios including debug tokens

@jeffheifetz
Copy link

@jkeshavarzi Did we used to have a warning for missing buildId that will now not get hit?

@jamesjhedley
Copy link
Member

@jeffheifetz I believe the behavior is it will show a warning if you provided a password but no buildId.

@EricLeiLi
Copy link
Author

My change shouldn't affect signing as it only modifies the internal variable "xmlObject" which will be used to generate bar-descriptor.xml. When we sign the bar file, we checked beforehead and it uses command line to specify buildId but not use the value in generated bar-descriptor.xml. It only affects the case that user wants to sign his unsigned bar manually, however in that case, they should specifcy buildId though command argument provided by the signer.
My fix is the fail safe for build and release because the build will fail without buildId placeholder which no one can do anything at that point.

@jamesjhedley
Copy link
Member

I'm kinda with @jeffheifetz with this one. I feel uneasy forcing a buildId on the user. I can't say for sure if this would cause any issues. I don't think it would... but who knows. What happens if they try and sign their unsigned-bar afterwards and a buildId of 1 was already set? Would it have issues signing?

@EricLeiLi
Copy link
Author

Before they cannot sign the bar, either, because of no buildId. Now it has a dummy buildId. But either way, if they choose to sign it manually, they need to specify the buildId at that time. It won't cause issue in the real environment when people are trying to sigh his application seriously. Without the fail safe, build will fail for build and release and build and release staff won't fix it for us, that's why we need some fail safe method.

Fixed the unit test "exec blackberry-nativepackager"
@ericpearson
Copy link

I still think we don't need a build id, I never specify one when I use the native packager/signer and it always works, maybe my computer is magic I don't know

@ericpearson
Copy link

I understand this is needed for qnx, I opened an issue for something else related to build id

@jamesjhedley
Copy link
Member

@Pagey Are you sure you aren't trying to sign a bar that already has a build ID set internally? Maybe that's why it works for you? Not sure, just a random thought...

@EricLeiLi
Copy link
Author

Currently if the user specify version=1.0.0.xxx, xxx will become buildId. It can be used as a solution for build and release. So I will close the pull request for now.

@EricLeiLi EricLeiLi closed this Nov 28, 2012
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.

4 participants