1422203 - create a source readme instead of a source tarball

Status: RESOLVED FIXED

(Release Engineering :: Release Automation: Other, enhancement)

Description

[Aki Sasaki (not active)]

In bug 749312, we were given permission to create a source readme instead of a source tarball. This will save us cycles, disk, and (once this is done) human configuration time.

Comment 1

[Aki Sasaki (not active)]

Attachment: add SOURCE{,.asc} to beetmoverscript templates

Comment 2

[Aki Sasaki (not active)]

Attachment: puppet_sign_source.diff

I'm open about naming. SOURCE is the current filename.

Comment 3

[Mihai Tabara [:mtabara]⌚️GMT]

Nice to see this change to reduce some of the resources we're consuming.
Will review and integrate the beetmoverscript PR in my existing PR for the firefox-intree, if that's okay.
Thanks!

Comment 4

[Mihai Tabara [:mtabara]⌚️GMT]

Comment on attachment 8933531 [details] [review]
add SOURCE{,.asc} to beetmoverscript templates

LGTM, thank you!
Addressed a tiny comment in the PR.

Comment 5

[Mihai Tabara [:mtabara]⌚️GMT]

(In reply to Mihai Tabara [:mtabara]⌚️GMT from comment #4)
> Comment on attachment 8933531 [details] [review]
> add SOURCE{,.asc} to beetmoverscript templates
> 
> LGTM, thank you!
> Addressed a tiny comment in the PR.

Merged and rolled-over into 3.3.0-dev10 on dep beetmover.

Comment 6

[Aki Sasaki (not active)]

All good, except we need to fake a balrog_props.json =\

Comment 7

[Mihai Tabara [:mtabara]⌚️GMT]

(In reply to Aki Sasaki [:aki] from comment #6)
> All good, except we need to fake a balrog_props.json =\

I've been thinking of this issue for a while. Because of the balrog_props.json file, beetmover is not as robust and easy-to-use, not even as the old mozharness one used to be. I'm thinking we should brainstorm on this maybe in Austin. If we do this right, I think we might get away with just:
* defining a set of variables that are absolutely needed for any type of beetmover job
* define an optional set of key:value specific for each different type of beetmover job
* if we have balrog_props: get_stuff_from_there() else get from payload.

I'm really hoping this is not as complicated as it sounds and we can get away with more rubstness.

But until then, we can make the source file job be (temporarily) dependent on the Build and get the balrog_props from there.
How's that sound?

Comment 8

[Aki Sasaki (not active)]

Aha! Yeah, depending on the build will work.
Yeah, I added a trello card to get rid of balrog_props.json entirely, and defining those values at graph generation time. Ideally we can pass these values into the build if we need them there (like buildid).

Comment 9

[Aki Sasaki (not active)]

The beetmover fixes are in bug 1413219.
Marking as fixed on maple.